Posts Tagged ‘development’


Has Your Agile Ship Sailed?

December 8, 2010

Sorry agile purists.  In the real world, most development groups that are using agile techniques (a surprisingly small percentage vs. the industry hype) are not using a “pure” agile approach.  They are using a blend of agile and waterfall techniques to the tune of more than 10 to 1, according to a recent article on Application Development Trends.  The article discusses a European survey of this topic published by a tool vendor.  (Caveat Emptor – Remember if you choose to download and read the actual “study”, it is really a vendor marketing piece based on the survey results – not the actual survey).  I guess the assertion that “waterfall is dead” is as premature as that of the mainframe also being dead.

 Is anyone surprised?  Contrary to what we are constantly barraged with by the agile marketers shouting “Agile, agile!” there is no need to swallow the agile elephant whole.  If you are in an organization that is not using agile techniques, don’t be tempted to lunge headlong into adopting everything agile, just because think you are missing the boat.  Not so.  This article / survey show what other studies have recently shown – that organizations doing agile are not (yet) in the majority.  Another indicator is that the primary tools being used to manage agile projects are still Microsoft Excel and Project.  And many groups are just using ad-hoc tools or working manually.

 So you still have time.  Learn from the majority of the organizations surveyed and adopt agile practices a few at a time.  Target the areas where you have the most problems and try out some lightweight practices.  Find out what works for you, give it time to diffuse into your organization, and then move on to adding additional practices. 

 What you will find is that it is not usually about the tools or about the agile practices themselves.  Most of the challenges in agile adoption are about people and organizations.  This survey cites resource management, cultural issues, change management, perceived loss of control, and executive buy-in as major stumbling blocks.  A “tools first” approach will not solve these.  Nor will a process-only approach.  While you are adopting more lightweight techniques, also look at your people issues and assess whether those can be resolved.  Otherwise they will be the rocks upon which your agile ship will run aground.


What Would You Like To See…For Free?

August 17, 2010

We are beginning a project to develop freely available online content. But first, we need your opinion on what topics this content should cover. Please take a moment to answer these five quick questions so that we can provide you the information that you need. Click here to go to the survey. Thanks for your input.


Don’t Rewrite the UML

May 25, 2010

In software development there are best practices there are also worst practices. When bad practices become a common pattern of behavior they can attain “anti-pattern” status. In this article, I’d like to introduce you to the “I Did It My Way” © anti-pattern. Read about it at If you are interested in additional articles, you can find more at


Fun With Frames and the User Experience Model

April 12, 2010

Development teams don’t necessarily receive “requirements” from their stakeholders as use cases, textual requirements, user stories, or even “drive-by requirements” (where the stakeholder throws a yellow sticky note – that contains their latest requirement – over your cubicle wall as they walk down the hallway). And sometimes the end users (an important stakeholder) are so focused around the user interface of the system, that suggesting changes to their user interface is the only way they know how to express their needs.

The advice you commonly hear regarding using the UML© for user interface modeling ranges from “don’t do it” to (at best) “create a User Experience (UX) model”. The UX model as traditionally described is good for simple situations, but with the advent of more modern, complex UI presentation options, the traditional UX model’s utility begins to reach its limit quickly.

I was pleased to find an elegant answer available in a little used area of the UML© that does not get delved into deeply very often…Read more


A Fool With a Tool…

February 25, 2010

So often, the development teams I coach on modeling ask “What free UML tools are out there?” As you probably know, there are quite a few now. But the problem with asking that question is these teams often have already purchased a modeling tool! Why don’t they ask earlier?

Many times the people who will be the end users of the tools are not (or just marginally) involved in tool selection. Some process or tool group is often commissioned to survey available tools, assess their applicability, and recommend what should be purchased. The tools are purchased, deployed, and then the end users find out that the tools don’t quite fit the manner in which the team actually works. This is a classic problem with a “tools first” approach to process improvement. Tools must support the way you work, not force you to work their way.

I was a member of such a tool committee at a company that was consensus driven in the extreme. We were directed to gather every possible stakeholders’ ideas on what criteria should be used to evaluate the tools. We ended up with a matrix of 123 different criteria. Did the people who would actually use the tools regularly use 123 different tool capabilities? Of course not. When the actual decision was made, after struggling through weeks of gathering, clarification and prioritization of all these decision criteria, the final decision came down to only 3 core criteria. It would have been a more pragmatic activity and much time would have been saved if we had known those 3 key criteria at the start.

But if modeling is new to your environment how would you know what you need? You may not have yet established how you are going to work with modeling. How about trying your new modeling practice with some of the open source (often free) tools? In this way you can easily and inexpensively discover what you really need in a tool for the level of modeling you intend to do. Not everyone does full Model-Driven Development. You may need only some simple diagramming capability. Maybe you won’t need that expensive gold-plated modeling tool. Every development team / organization is different. You may discover that a more modest tool may be sufficient to support your way of working.

If you want to read a nice survey of open source modeling tools read more at


The Bite of Agile Dogma

January 22, 2010

An often heard complaint about heavily plan-driven development approaches is that they are too heavy, too rigid. This criticism is not unjustified. However, we need to be careful. There is a non-trivial number of “agilists” who are sounding like the waterfall autocrats of the past. You hear them passing judgment that you are not “really” doing agile because you are not adhering to the letter of the agile law as prescribed in some revered agile tome. You’re not doing continuous integration? All you people are not certified? You’re creating some documentation? Well then you’re not agile.

This is unfortunate as these folks are missing one of the greatest value of agile (or other lightweight) techniques – – they can be easily blended together, even with more traditional approaches, to give you an effective, customized process that will work well in your particular development culture. Your approach, however agile it is, must work in your specific environment and support the way your teams work.

Chuck Cobb writes a good article on this topic. Take a look.

–Bob Maksimchuk (