My presumption was that the concept of agile software development is still relatively unknown, so I would need to define the concept in an easily digestable way.

Our team has practiced agile software development since it was introduced in the late 90′s. In fact, we formed our company with many of the same philosophies because the founders originally worked together as an agile software team.

Before that, we had all practiced much more formal methodologies, having been trained in big government shops like SRA, Lockheed Martin, and the military.

Since then, I have evolved into an evangelist for the concepts outlined in the agile manifesto. But lately I have found myself having to “sell” this approach less and less.

So I wonder: has agile has gone mainstream?

Last March I was invited to present to the Software Process Improvement group at the U.S. Census Bureau with a former colleague, Marsha Acker, CEO of consulting firm TeamCatapult. Our presentation was entitled ‘Where Agile Meets the CMMI’. Our conclusion was that Agile methods and the CMMI framework were actually compatible and complimentary approaches to software development…but we expected pushback and doubt.

When I was a consultant to the federal government, this topic would have been taboo. CMMI (or more correctly its predecessor at the time CMM) was the holy grail of process improvement and software quality assurance. “Agile” was a revolutionary movement – a perceived way to get out of doing the hard stuff and avoid documentation, planning, and project management.

But the folks at the Census Bureau didn’t need to be sold. They were not only accepting of the idea that these two good ideas could go exist, they were way ahead of us in asking nuts and bolts questions about “how” to put it into practice. Like right now!

I am very glad that the world seems to be accepting agile methods, but in truth successful adoption and implementation of these techniques does take some discipline, training, tools and appropriately trained people to implement.

One thing is clear to me – regardless of how mainstream, it’s time to start innovating – how do we make it work better and what are the specifics? I hope we can cover these concepts in subsequent posts.

package example;

import java.io.Serializable; 

/**
* Note that ID could be more generally defined as Serializable, but long worked best in this situation
*/
public interface PersistentLite extends Serializable
{
   long getId();

   void setId(long id);
}
The relationship is the classic parent-child relationship.  This is our parent interface:
package example;

import java.util.Set;

/**
 * In practice, the set of children should be restricted to instances of Child, but type parameters do not display well in HTML,
 * so we use the raw type in this example.
 */
public interface Parent extends PersistentLite
{
   Set getChildren();

   void setChildren(Set children);
}
Here's the child.  In this case, the child also has a couple of different implementations, so it is also defined as an interface:
package example;

public interface Child extends PersistentLite
{
   Parent getParent();

   void setParent(Parent parent);
}
Here are the mappings for parent and child:
<hibernate -mapping>
  <class name="example.Parent" table="parent">
    <id name="id">
      <generator class="native"/>
    </id>
    <discriminator />
    <set name="children" cascade="all-delete-orphan" inverse="true">
      <key column="parent"/>
      <one -to-many class="example.Child"/>
    </set>
  </class>
</hibernate>
<hibernate -mapping>
  <class name="example.Child" table="child">
    <id name="id">
      <generator class="native"/>
    </id>
    <discriminator />
    <many -to-one name="parent"/>
  </class>
</hibernate>
You would then add implementation classes and mappings, these are representative:
package example;

import java.util.*;

public class ParentImpl implements Parent
{
   private long id;
   private Set children = new TreeSet();
   private String extraData;

   public long getId()
   {
      return id;
   }

   public void setId(long n)
   {
      id = n;
   }

   public Set getChildren()
   {
      return children;
   }

   public void setChildren(Set set)
   {
      children = set == null ? new TreeSet() : set;
   }

   public String getExtraData()
   {
      return extraData;
   }

   public void setExtraData(String s)
   {
      extraData = s;
   }
}
package example;

public class ChildImpl implements Child
{
   private long id;
   private Parent parent;
   private String extraData;

   public long getId()
   {
      return id;
   }

   public void setId(long n)
   {
      id = n;
   } 

   public Parent getParent()
   {
      return parent;
   } 

   public void setParent(Parent p)
   {
      parent = p;
   }

   public String getExtraData()
   {
      return extraData;
   } 

   public void setExtraData(String s)
   {
      extraData = s;
   }
}
<hibernate -mapping>
  <subclass name="example.ParentImpl" extends="example.Parent">
    <property name="extraData"/>
  </subclass>
</hibernate>
<hibernate -mapping>
  <subclass name="example.ChildImpl" extends="example.Child">
    <property name="extraData"/>
  </subclass>
</hibernate>
The key insight is this: because the interfaces are mapped, Hibernate generates proxies that implement the interface, which eliminates a lot of potential casting problems.   By contrast, if you use class inheritance, Hibernate can only generate proxies that implement the interface which the class exposes to Hibernate, and is not necessarily the same as the interface exposed to the system at large. This causes confusion.  Moreover, since a lot of casting issues can occur from inside the subclass, via private methods and data, using an interface eliminates a lot potential problems because the interface is well-defined.  You could still run into issues when casting, but they are greatly reduced if the interface is properly defined.  Finally, using a lightweight interface as the basis of the relationship gives the implementation the flexibility to inherit from a richer base class if desired.

Each wireframe is essentially a rough sketch of a page in the system, along with an overall description of the page and numbered annotations describing how each component of the page will work. The annotations are a great place to capture rules for validation, dependencies, etc.

A site map should accompany the wireframes, which establishes the site’s basic hierarchy. This provides context and helps the viewer understand how the wireframes fit together.

Before wireframing any project, the analysis team should have a level of confidence in the overall stability of high-level project goals and requirements, as well as a shared understanding of the basic system architecture. Obviously, requirements are somewhat fluid by nature and some uncertainties will remain at this stage in the project – but the key to reducing costly amounts of re-work is to minimize these uncertainties to the fullest extent possible by talking through the approach with team members.

I’ve found that wireframes engage the customer far more effectively than long lists of “The system shall…” statements. However, no single requirements artifact is perfect, either.

Wireframes can be somewhat dangerous because:

• they can make false promises about layout or system functionality if they are not reviewed with a fine-toothed comb;
• if they are initiated too early in the analysis phase (very fluid requirements at this point), it will take a significant amount of time to incorporate major changes;
• they can interfere with the creative talents of the design team if they are over-engineered or stylized; and
• they will eventually reach a point of diminishing returns, once stakeholders have an overall “feel” for the system but want to incorporate small changes that don’t need visual representation (tools such as JIRA are useful for capturing requirement changes at this stage in the game).

However, wireframes can be extremely valuable because:

• they provide a somewhat stable UI concept at the outset of the development phase, significantly minimizing rework due to stakeholder misunderstanding of how the requirements translate into user interface components such as radio buttons, checkboxes, etc.;
• they help illustrate requirement dependencies and the impact of those dependencies on the level of effort required to accommodate certain types of change requests;
• the review process is much easier for stakeholders, and timeliness/quality of feedback is enhanced;
• in conjunction with workflow diagramming, they can clarify the scope of complex process requirements amongst all stakeholders;
• in conjunction with annotated specifications, they can expand on the inner workings of the system which may not translate visually (such as linking validation to specific UI elements);
• they often uncover potential gaps in process concepts early in the lifecycle; an
• they often uncover usability issues that are inherent to the stated requirements, allowing for those requirements to potentially be adjusted to optimize the way they are implemented.

I’d love to get some feedback on this, particularly in terms of pros and cons I may have missed.

Dave Leonard is a Business Analyst with Phase2 Technology.

We specialize in the “Agile Approach.” I assumed it just meant flexible – little did I know how much there is to agility. I ended up here after working with Phase 2 as a client, and had often told people of their iterative approach to web development – without realizing I was only partially explaining the concept of the agile approach.

My research started with Wikipedia.

There I learned about the existence of an Agile Manifesto. A manifesto? Really?

Folks around here, having been practioners for years, wonder if the agile approach has gone mainstream.

I’m just learning all it encompasses. When I read more, I find myself thinking, “yes, that’s it. That just makes sense.”

If, like me, you aren’t familiar with the Agile Approach to software development, check out these great resources:

http://www.phase2technology.com/approach.php

http://martinfowler.com/articles/newMethodology.html

http://www.agilealliance.org/show/2

http://www.agilejournal.com/magazine.html

I think you’ll also find yourself nodding and thinking, “yes, this is the approach I want my web developers to use.”

Google Collections – This library is an extension of the Java Collections Framework, with complete support for Java 5.0. The support for Java 5.0 is an important aspect of this library since it leverages the power of generics, which is a major concern when dealing with collections of objects in Java. This is one of the major differentiators between this library and the Apache Commons Collections library that I have used in the past. Google Collections also aims to simplify your code by allowing you to get rid of boilerplate code that often is necessary to deal with the standard Java Collections classes. This definitely is in line with our coding practices at Phase2, especially the desire to make our code simple and self-documenting.

Google Charts – Because of my past involvement with business intelligence products, I was interested in how Phase2 develops reports and charts in many of their custom web applications. While we currently use JFreeChart to build graphical charts for some of our applications, I recently discovered Google Charts and liked what I saw. The chart at the right shows Google’s weekly stock price over the course of 2007. It took me about 30 minutes to build this chart, and hopefully I could improve on that time as I get more familiar with the library. (To see the magic behind producing this chart, view the properties on the image to right.  Note the parameters in the URL.) Google Charts is a web service that takes in a whole bunch of parameters and the data for the chart, and returns a PNG-format image with a chart of the data. It supports several different types of charts and appears to be quite flexible. Google Charts does have a limit of 50,000 queries per user per day. However, I see it as an extremely viable option to quickly deliver charts for a small or medium size application without the overhead of learning and deploying some other reporting framework.

Google Web Toolkit (GWT) – This framework has created quite a buzz over the last year or two, and I still haven’t found the time or right opportunity to give it a try. It allows you to develop AJAX applications completely in Java, and then uses the GWT compiler to convert your Java classes into JavaScript and HTML that is compatible across a wide variety of browsers. For a company that doesn’t have a lab with every feasible combination of browser and operating system or the people to test our applications across all these different combinations, GWT appears to be a very compelling solution as we start to develop custom web sites with requirements for more Web 2.0 features. It’s also the agile developer’s dream for developing AJAX functionality, since you can use a unit testing framework like JUnit to test out your classes before they are compiled to JavaScript and HTML. This allows the agile developer to increase the coverage of his or her unit tests, decreasing the time it takes to initially develop a new feature correctly and increasing the stability of an application as it changes over time.

I selected these three applications because they provide functionality that could save me many hours of development on a future project. I’ve always been the kind of person that’s lured by the practical solutions versus the ones that are just cool and flashy, so hopefully these three apps satisfy my need for practicality before 2009 arrives!

Steve is a full time Java developer at Phase2 Technology and a part time stock market watcher who wishes he bought Google stock when it was $100!

Picking features for your organization’s website can sometimes feel like you’re ordering from the drive through at Burger King. But at Burger King you know exactly what you’re getting and exactly how much it will cost. But have you thought about the costs after you scarf down that double Whopper with cheese? The indigestion, the big butt, the extra 30 minutes you’ll need on the elliptical at the gym? Okay, so I’m being silly, but I’m trying to make a point. That’s kind of the way websites are.

Launching a great website is only the start of your organization’s investment in its online presence. It’s after launch when things can get dicey. Have you thought about who is going to maintain your CMS? Have you thought about how you’re going to get reports out of your CRM? Do you realize that a website isn’t a one time investment? It’s an ongoing affair that requires upkeep, care, and a whole lotta love.

Here are some tips for preparing your organization’s management for understanding that buying a website is not all that different from buying a car. It needs its’ oil changed.

• You will encounter completely unforeseen circumstances. A server hard drive will crash. A network will fail. There will be a “glitch.” Be prepared to pay for fixing these problems even though they aren’t your fault. They might not be anybody’s fault.
• Know that your website is not perfect. All software systems will break down occasionally. Have money set aside for future bug squashing and upgrades.
• Train your own people on how to maintain your CMS. Knowing some simple web technologies, like HTML and manipulating images with Photoshop, can provide you with the firepower you need to keep your site up to date and looking great.
• Don’t be helpless. Learn how to use the administration features of your site. Know what your system is capable of and don’t be afraid to use it.
• Realize that your website’s success is a direct result of your organization’s willingness to work hard and take accountability for it. Don’t expect your development team to do everything for you. No one knows your business better than you, so take some action and get in there and get your hands dirty.

Getting some of these basic principles right early on can be the difference between a happy, healthy website owner, and a grumpy one with buyer’s remorse.

Michael Morris is a Senior Solutions Architect at Phase2 Technology and spends much of his day making sure you get the most out of your double Whopper with cheese.

Introducing AJAX Views , a custom module written by Phase2 and contributed back to Drupal.org. This module allows you to specify a view block as paging via AJAX. It also provides a myriad of ways to theme these blocks and ajaxified pages. Drupal module development is challenging and incredibly flexible and it is also a large part of what makes the Drupal platform and community so special.

Give AJAX Views a try, tell us what you think.

Frank Febbraro is CTO of Phase2 and if he could find a way to develop software while mountain biking, he would die a happy man…..most likely from a crash.

There is an undocumented “feature” that I discovered while scouring the source code in my bid to extend update_status to allow external status reports. It seems you have the ability, in your modules .info file, to specify the base URL that update_status will check to see if there are subsequent releases of your modules. In your modules .info file you will add something like

project status url = http://some.host.com/drupal-module-releases

For example the default URL for drupal.org is http://updates.drupal.org/release-history The format is for update_status URLs are as follows: baseurl/modulename/version , so the url to check versions of the views module for Drupal release 5.x is http://updates.drupal.org/release-history/views/5.x

There might be some more to this, some details I have left out, etc. I’ll let you know once we implement it.

I also added this as a comment to the Drupal handbook page for .info files. http://drupal.org/node/101009

   Frank Febbraro is CTO at Phase2 and loves getting into the guts of things.

My goals as I embarked on the search for the ideal PHP Web Framework were pretty simple and straightforward. I was looking for a set of tools that would provide the following:

• An action-based framework that would be simple to use and intuitive for other developers to learn and jump into should they need to build more functionality or modify existing code
• Support for developing and executing unit tests for these actions without needing an HTTP context
• Some kind of proxy or layer of abstraction to assist with running queries against the database
• Separation of the view technology into a template-based framework

The first frameworks I investigated were ones that claimed to have everything built in, all the way from UI to database persistence and everything in between. Examples of these frameworks are symfony and Zend Framework. While these might be feasible solutions for someone looking to build an enterprise website, I found these solutions too complicated to learn quickly and too tightly coupled such that you couldn’t easily unit test outside of an HTTP context or roll in a different technology for a specific portion of the functionality (such as a new template engine or database abstraction tool).

The next framework I discovered was Code Igniter. I thought that this framework might be the solution to all of my problems. I really liked the modular approach and all the utility classes that would certainly save me many hours of development time. But after playing around with it for a little bit, I found that things were still too tightly coupled for my liking. And as a Java developer who has relied upon the features of JSPs and tag libraries for quite a while, the fact that Code Igniter shies away from using a template engine is less than ideal.

I finally came across Tiny MVC and decided to use it as the foundation for the application I was building. It met all of my requirements and was simple to learn and even extend or customize where necessary. The best features of Tiny MVC in my mind are its simplicity as well as its abstraction of the HTTP request and session objects, which made unit testing my actions a breeze. In order to provide some additional functionality, I also decided to use PEAR’s DB_DataObject for accessing the database and Smarty as my view or template engine. Finally, I used SimpleTest in order to run all of the unit tests for both the core application logic as well as the higher-level actions that are a part of the Tiny MVC framework.

So what lessons did I learn from all of this? Well, I learned the following:

• Compared to the Java landscape, the PHP framework world is a little chaotic. The PHP frameworks that appear to have the widest adoption are also the ones that provide the most functionality (typically in a tightly-coupled manner). This is great if you are out to build enterprise applications with PHP, but I was just looking for a framework to get me started with the basics. I will typically only build small and relatively simple applications with PHP, and switch over to Java once things start to get more complicated.
• There does not appear to be very robust support for unit testing, which is one of the key aspects of Agile development. It seems kind of crazy that PHP, which is better suited for rapid development than Java, actually has less support for unit testing in its frameworks.
• Simplicity and ease of adoption, at least in my mind, is directly related to the amount of functionality that a framework provides. As a framework expands its scope, it becomes harder to understand and adopt. I believe this is one of the reasons that many of the Java frameworks are easier to adopt than their PHP counterparts. Java frameworks like Struts, Hibernate and Spring are primarily focused on one aspect of the web application stack. They don’t try and do it all, and instead make it easy to integrate other technologies into their frameworks.

Steve is a Software Developer at Phase2 Technology.

Most project managers see planning as the first and most helpful step they can take towards getting their projects off on the right foot.

Yet, in the process of planning, PMs often miss the forest for the trees. Forgetting to re-plan your project, missing the business case, or building a project plan that is too complicated for the effort it is meant to support can doom your plans to failure.

In this blog entry, I’ll talk a bit about each of these risks, and how to avoid them.

The GANTT Chart of Doom

Too often, I come across incredibly complicated project plans, with hundreds of individual tasks and dozens and dozens of interconnected milestones. The resulting “wiring schematic” is impossible to read or interpret by the PM that created it, let alone others who work in different business functions.

Let’s not forget a crucial lesson of the PMBOK: project management is as much about communication as it is anything else. When your project plan becomes huge and unwieldy, you’ve lost a vital communications tool. Your plan has now landed solidly in the project management “silo”, of dubious value to others on your project team

Furthermore, a plan like this will require more work to keep it up to date in the future (we’ll get to this next). In my experience, an overly complex plan is more likely to be quickly overcome by events, and therefore of little use to anyone as the projects moves ahead.

Don’t get me wrong – there is value in working through the complete set of risks and dependencies – no doubt you’ll realize some you didn’t know existed. And more complicated efforts where the dependencies involve months of lead time and potentially expensive re-work may necessitate this type of planning.

Yet, once you’re done developing your complex plan, it’s important to take a step back and simplify when possible. Ask yourself – is my plan overly complicated for the effort I’m managing? Here are some questions that may help you along -

Am I simply exposing common sense dependencies that the team sees easily, without my help?

It’s important to take into account your team’s capabilities. If you’re building web site similar to a series of previous web sites built for the same customer using the same core team, recognize that there are likely well-understood risks, tasks, and dependencies fully understood by your team. Target your planning for the unique risks and opportunities each project presents.

Have I broken down task responsibilities for resources that are beyond my purview, or in a way that can’t be predicted realistically?

In my experience, if you’re assigning tasks to the person-level beyond a 2 month time range, you’re probably down at a too-low level of detail. Events happening far in the future are less clear than events happening in the near-term – acknowledge that uncertainty. Don’t deceive yourself into thinking you know “the how and who” when you really don’t.

Is a large percentage of the plan dedicated to tasks that lay off the critical path, items that are of low cost, and/or have very low expected variance in either schedule or cost?

It is common sense to focus on the areas that could, with a few small mishaps, put the project vastly over budget or behind schedule. Again, tailor your plan strategically for the maximum impact. This will keep it simple, maintaining it’s usefulness as a communication tool, while keeping your focus on the things that matter.

Hey, Where Did My Plan Go?

Another common mistake amongst new project managers is not realizing that plans must be re-visited frequently as the project unfolds. The fact is, projects never go exactly according to plan, and project managers need to accommodate for that by re-planning often.

The notion that change is unavoidable and therefore must be embraced for project success has practically spawned the newer Agile methodologies all by itself. Note that change can be “good” change – say, your company lands a big new contract that will require a juggling of resources – or a “bad” change – your estimates were optimistic and need to be adjusted. Note that in this latter case, this is not “change” per se, but simply reality happening. Things happen, and project managers must be prepared, with contingency plans if necessary, but at the very least with a revised plan.

As you re-plan, consider the quality of your re-planning data. Now that the project is underway, are you getting high-quality and meaningful data on how things are going? Agile methodologies hold that there is no substitute for real, live, working software. I think it’s worth considering that credo, no matter what industry you work in. Take some time to “manage by walking around” – verify progress reports occasionally and get a feel for how things are unfolding. In doing so, you may discover risks you didn’t know existed, or you may discover your plan needs to be updated, and fast.

Why Are We Here Again?

Finally, as you plan the project, don’t forget the business problem the project is trying to solve. Does it exist? Has it been stated and mutually understood by stakeholders? Do we have an order-of magnitude cost estimate, along with preliminary project approval? Do we understand the “how” of our solution?

It’s easy to forget that according to the PMBOK, planning is not the first phase of a project – project initiation is. Too often, projects get planned in extraordinary detail, only to discover later that the problem is in fact different than the one we thought we were trying to solve. Or maybe our planned approach did not meet our original assumptions – maybe it’s not technically feasible, possibly just too expensive, or takes too long.

It’s important to have the business case in mind not just before planning begins, but throughout the life of the planning process and the rest of the project. As such, your planning efforts may cause the whole project to be re-evaluated. On smaller or more Agile projects, this may be as simple as calling a quick meeting, or on larger projects, a significant process of regulatory-style approval. Either way, the sooner this happens, the better. It’s no fun being 75% through a project, only to realize the business case got missed.

Summary

• Consider applying “necessary and sufficient” principles to your project plan. Build your plan to strategically highlight the areas containing the most schedule or cost risk.
• Planning occurs throughout the whole project lifecycle, not just at the beginning
• Don’t forget the business case – the critical “why” of the project. Just like planning, it must be revisited as often as necessary.
• Finally, remember that the flow of project process is not purely linear – initiation, planning, and execution all happen simultaneously to a degree – informed by the monitoring and control processes you’ve established.

Rich is a PMP certified Project Manager, that is kinda like USDA Prime.