Departing Waterfall – Next Stop Agile


It’s been more than a year since I penned, “Before Making the Leap to Agile“, an article intended to guide everyone from C-level executives to IT project managers on the adoption of Agile. The goal was to offer up some of the lessons I learned through actual implementations, so that readers could avoid of some of the pitfalls associated with Agile adoption.  While a few saw it as an assault on Agile, many understood that my goal was to assist Agile adopters and thanked me for writing it.

Five-thousand-plus page views later on the last article, and I’ve finally cleared my plate enough to address an equally important topic, why people, and organizations, are making the shift to Agile from the more typical Waterfall. After all, Agile is a revolutionary approach to software development and it continues to grow in popularity, so I think it’s important for those who do not yet use Agile to understand why others have embraced it.



R.I.M’s Live or Die Moment


It seems ridiculous almost to the point of being sublime to suggest that Research in Motion, the maker of the BlackBerry, is in need of a turnaround. Yet, if you listen to the pundits of the technology industry, it seems as if Research in Motion (R.I.M), the Canadian technology powerhouse, is on its last legs and will soon be plowed under by the onslaught of Apple and Android technology. And, even though the company shipped a record 52.3 million phones in the last fiscal year, a sharp 43 percent spike over the previous year, and, its fourth-quarter income of $924 million exceeded forecasts, people are saying that the company is going to be the unwitting star of an industry movie called “Palm: The Sequel” as a result of its aged technology platform and paucity of applications for that old operating system.  More

Amazon Says, Hey, Look at Me, I’m Flying

Leave a comment

Amazon, the online retail behemoth, has decided to forgo that pesky thing called a music license as it launches their Amazon Cloud Drive, a “virtual” place where Amazon customers can store their digital music on Amazon’s gargantuan servers. Once stored, Amazon facilitates “streaming” of those music files to a computer or handheld device through Amazon Cloud Player.

Amazon has taken the position that they don’t need a license because their customers are only going to store and stream music that they already own. It looks like the record companies may not agree with that point of view. They’re either staying mum, or, as in the case of Sony, “reviewing their options”.


Rovio Mobile, Developer of Angry Birds, Gets $42 Million in Funding


The newest overnight sensation of the digital gaming industry has now officially been crowned. Rovio Mobile, a tiny mobile gaming company out of Finland run by Niklas and Mikael Hed (cousins), has ridden their Angry Birds game to lofty marketplace success (40 million active users) and a financing round of $42 million USD, led by Accel Partners and Atomico Ventures. 

Of course, someone gets the obligatory board seat, and in this case, that someone is Niklas Zennstrom, a co-founder of Atomico Ventures, as well as another company named Skype. He is going to sit on the board of Rovio Mobile, his new investment. He also issued the even-more-obligatory statement, saying, “Angry Birds is one of the fastest-growing online products I’ve seen, growing even faster than Skype, and the company has done a brilliant job of extending it across different platforms and merchandise.” 

It’s worth noting that little Rovio put out 50 titles before they went platinum with Angry Birds, courtesy of the explosion in smart phones; now that they have a thoroughbred in their stable, they intend to ride that horse until they can breed another winner. 


Intuitive to Whom? (In Web Design, it Matters)

Leave a comment

During a recent Management Information Systems course I taught for the University of Phoenix, I posed the discussion question to students, “What do you think are the most important qualities that determine a well-designed user interface?” While responses were very good, nearly all of my students used the term “intuitive” in their response without providing a more detailed description, as though the term has some universal, unambiguous meaning to user interface (user experience) designers and web users alike.

I responded by asking, “Intuitive to whom?…Would a college-educated individual and a new-born infant both look at the same user interface and agree it is intuitive? Or, would the infant prefer a nipple providing warm milk to embedded-flash videos of news stories?”

Far from obvious, an “intuitive” user interface is extremely hard to define because “intuitive” means many different things to many different people. In this article, I challenge the assumption that “intuitive” is obvious and suggest how we can determine what intuitive “is”.

Nature and Nurture

Our exploration of intuitive user interfaces and user experience starts with “nature” and “nurture”, much like the “Nature versus Nurture” debate that occurs when explaining the talents and intelligence of human beings. For those of us who haven’t opened a genetics book in a few decades, if ever, “Nature” assumes that we have certain talents at birth, while “Nurture” proposes that we gain talents and abilities over time.

Certainly, “Nature” plays a role in an intuitive user interface. According to research by Anya Hurlbert and Yazhu Ling, there’s a great deal of evidence that we are born with color preferences and that color preferences naturally vary by gender. In addition, warning colors like red or yellow, such as red on stop signs and yellow on caution signs, are likely a matter of science and genetics rather than learned after we’re born. So, an “intuitive” interface is partly determined by our genes.

“Nurture” also plays a big role in determining our preferences in a user interface. For example, link-underlining on web pages and word density preferences are highly dependent upon your cultural background, according to Piero Fraternali and Massimo Tisi in their research paper, “Identifying Cultural Markers for Web Application Design Targeted to a Multi-Cultural Audience.” While research in personality and user interfaces is still in its infancy, there’s a strong indication that CEO’s have different color preferences from other individuals, as Del Jones describes in this USA Today article.

But, what about navigation techniques, like tabs and drop-down menus? In a recent conversation with Haiying Manning, a user experience designer with the College Board, I was told that “tabs are dead.” This crushed me, quite frankly, because I still like tabs to effectively group information and have a great deal of respect for Haiying’s skills and experience. As a Gen-Xer who spent much of his teen years sorting and organizing paper files on summer jobs, I’m also very comfortable with tabs in web interfaces, as are my baby-boomer friends. My Net-Gen (Millenial) friends seem to prefer a screen the size of a matchbox and a keyboard with keys the size of ladybugs, which I have trouble reading.

In the end, because of “Nature” and “Nurture”, the quest for an “intuitive” user interface is far more difficult than selection of a color scheme and navigation techniques everyone will like. What appeals to one gender, culture or generation is unlikely to appeal to others, so we need to dig further.

It’s all about the Audience

In looking back on successful projects past, the best user interface designers I’ve worked with have learned a great deal about their audience – not just through focus groups and JAD sessions, but through psychometric profiling and market research. This idea of segmenting audiences and appealing to each audience separately is far from new. Olga De Troyer called it “audience-driven web design” back in 2002, but the concept is still quite relevant today.

Once they better understood their target customers, these UI designers tailored the user interface to create a user experience that was most appealing to their user community. In some cases, they provide segment-targeted user interfaces – one for casual browsers and one for heavy users, for example. In other cases, they made personalization of the user interface easier, so that heavy users could tailor the interface based on their own preferences.

They also mapped out the common uses (use cases or user stories) for their web sites and gave highest priority to the most used (customer support) or most valuable (buying/shopping) uses, ensuring that they maximized value for their business and the customer. More importantly, the user interface designers didn’t rely upon the “the logo always goes at the top left” mind-set that drives most web site designs today.

Think about the Masai

In hopes of better defining what “intuitive” is, I spoke with Anna Martin, a Principal at August Interactive and an aficionado of web experience and web design. Evidently, “intuitive” is also a hot topic with Anna, because she lunged at the topic, responding:

“Would you reach for a doorknob placed near the floorboard; or expect the red tube on the table to contain applesauce? Didn’t think so. But what’s intuitive depends largely on what you’re used to.  Seriously, talk to a Masai nomad about a doorknob – or ketchup for that matter – and see what you get. And good luck explaining applesauce. (Cinnamon anyone?). Clearly intuition is dependent on what comes NATURALLY to a user – no matter what the user is using.

So why would the web be any different? It’s not. Virtual though it may be, it’s still an environment that a PERSON needs to feel comfortable in in order to enjoy. Bottom line is this…if you wouldn’t invite your 6 year old niece or your 80 year old grandmother to a rage (did I just date myself?) then don’t expect that every website will appeal to every user.

Know your audience, understand what makes them comfortable; and most importantly try to define what ‘intuitive’ means specifically in regards to sorting, finding, moving, viewing, reading and generally experiencing anything in their generation.”

So, audience-driven web design has firmly embedded itself into the minds of great designers, who must constantly challenge the conventions to create truly creative interactive experiences on the web. Consequently, as the field of user design transitions into a world of user experience, it’s going to require second-guessing of many of the design conventions that are present on the web today. This not only means pushing the envelope with innovative design, it also means we need to have a good handle on what “intuitive” really is.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy.  Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

Toward a More Robust Agile


In a previous article, I put together a list of some of the weaknesses of the Agile software development methodology that I’ve learned from other software experts and on my own as a consultant serving the technology industry.  As expected, some people were upset that I pointed out so many weaknesses in Agile without pointing out its advantages, believing I was being unfair.   It is true that there are many benefits to adopting Agile over other methodologies.  But, I was actually preparing fertile ground for my next article – Toward a More Robust Agile.

As you may remember, my last article identified ten weaknesses with Agile, including:

  1. True Agile is rarely practiced.
  2. Agile requires heavy customer interaction.
  3. Agile thrives with co-located teams, but struggles with distributed teams.
  4. Agile is difficult to scale for large projects and large organizations.
  5. Agile provides weak architectural planning.
  6. Agile has limited project planning, estimating and tracking.
  7. Agile requires more re-work.
  8. Agile makes contractual commitments difficult.
  9. Agile poses challenges to business continuity and limits knowledge transfer.
  10. Agile lacks attention to outside integration.

As I pointed out, these weaknesses should cause some organizations to hesitate before adopting Agile, particularly in large complex environments where most business processes are highly formal and the culture is risk averse.  C-Level IT executives (CIO/CTO), heads of software development, heads of PMO’s and lead project managers should research further before considering the leap to Agile seriously.

Fortunately, Agile is not a static, take-it-or-leave-it methodology, so variations, improvements and customizations are being made and adopted as I write this. One of these improvements, however, is worth an in-depth exploration.

Already understanding some of the weaknesses inherent in Agile, one software development expert began to address them in 2007 – Dean Leffingwell. In “Scaling Software Agility: Best Practices for Large Enterprises,” Leffingwell responded to many of the challenges posed by adopting Agile in large-scale environments, particularly items 2,3, 4, 5, 6 7, 8, 9 and 10 above. In doing so, Leffingwell made Agile both feasible and attractive to large businesses and large-scale software development projects – environments where Agile once struggled.

At the heart of Leffingwell’s approach is believing that Agile is inherently strong, but is not without flaws. In his own experience, he saw that some additional structure and planning were needed to coordinate large-scale efforts, much like I described earlier. Leffingwell’s response too beefing up Agile is five-fold:

  1. Make Architecture Intentional. Rather than treating architecture a byproduct of iterative software development, make architecture planned and deliberate. (Scaling Software Agility, Chapter 16)
  2. Use a Lean approach to requirements. First, define high-level requirements early, then hash out details when they’re absolutely needed, much like just-in-time inventory. (Scaling Software Agility, Chapter 17)
  3. Scale Agile using a team-of-teams, a system-of-systems and release trains. (Systems of Systems and the Agile Release Train: An Agile Whitepaper) . In Leffingwell’s scaleable Agile, the key to coordinating large software projects is to break them up into smaller ones and coordinate them, much like a program. According to Leffingwell, just as a group of interrelated projects are programs, a group of Agile teams can be combined to form a program team with program leadership, called a team-of-teams. Each Agile team focuses on a particular piece (component) of the software, or system, which combined makes up a system-of-systems. To pro-actively coordinate the team-of-teams building the system-of-systems, a release train synchronizes the iterations of each team so that their work meshes together at the end of each iteration, ensuring that the needed software features are delivered on schedule.    Beyond a specific release, epics tie many releases together, allowing for long range planning and architecture.
  4. Accept the distributed geography of software development teams and provide virtual tools to coordinate global efforts. In Leffingwell’s approach, a primary team is placed on-site with the client, while one or more off-site teams share work and coordinate with the on-site team using wiki’s, VoIP/Skype and web conferencing. (slide 87, 2007 presentation)
  5. Recognize that a shift to Agile is a major cultural change for a large organization, requiring stages and a roadmap. Rather than try to make the leap from Waterfall to Enterprise Agile all at once, Leffingwell suggests a five-step adoption path from individual Agile teams to multi-team programs and on to multi-program organizations. (slide 92, 2007 presentation).

Combined, Leffingwell’s Scalable Agile resolves many of the problems that large teams encounter with Agile, at least on paper. For me, I like that Leffingwell borrows from RUP (Rational Unified Process) and Lean manufacturing principles, two topics that I’m both familiar with and respect. I also like that he understands the large organization, the need for heavy coordination throughout, as well as the need for long range strategic, portfolio and architectural planning.

And, as you can see from the diagram below, this re-positions Agile to be more competitive with Waterfall and RUP for larger and more complex projects.

Agile methodology positioning

Agile methodology positioning

Not accepting theory alone as a solution, however, I talked with a friend who is implementing Leffingwell’s version of Agile-at-Scale in his organization to see how the effort is going, where the organization is encountering issues and whether he thinks Agile-at-Scale will work for them.  Though I can not reveal confidential information, he was able to provide anecdotal support for Agile-at-Scale, which is quite promising.

However, it would be great to hear from Agile experts who are implementing Leffingwell’s Agile-at-Scale or making similar changes to Agile to make it more robust.

Without providing confidential information, please tell us…

  1. How large is your organization (people, revenue)?
  2. How long has your organization been pursuing Agile?
  3. How long  have you been working with Agile-at-Scale?  How far are you through Leffingwell’s five step adoption path?
  4. Are you happy with the results you’re seeing?
  5. What are some of the biggest issues you’ve encountered to-date?
  6. Given what you’ve seen, do you think you’re Agile-at-Scale effort will succeed?

While it’s a little early to tell, Agile is clearly evolving to become more attractive to larger, more structured organizations and maturing to provide a viable alternative to Waterfall and even RUP.  When I return to this topic, I will talk about some ways to ease in to Agile, adopting Agile tools and techniques in your environment without completely abandoning a Waterfall approach.

Interested in other articles like this one?  Read “Departing Waterfall-Next Stop Agile“.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

Before You Make the Leap to Agile – Ten Weaknesses of the Agile Methodology


It’s been nearly a decade since Martin Fowler, Ken Schwaber and fifteen other experts in the software industry wrote the Agile Manifesto outlining an approach to software development radically different from the Waterfall model that dominated the 1980’s and 1990’s. Since that eventful time in 2001, Agile software development methodologies, including the use of Scrum, XP (Extreme Programming) and Crystal, are all the rage throughout business and government, attracting praise like a miracle drug. As of early 2010, Agile is till one of the more popular buzzwords in software development.

If you’re in the captain’s chair as a C-Level IT executive (CIO/CTO), the head of software development, the head of your Project Management Office (PMO) for your business, or the lead project manager in a small organization, you may be considering the leap to Agile seriously. The good news is that Agile is working well for many businesses and on many software development projects.

The bad news is that Agile is not the magic bullet many are claiming it to be. As many successes as there are in Agile development, there are also many failures in both the adoption and use of Agile in software development. (Here’s a list here of some cautionary tales, provided to support my statements, not to complete turn you away from Agile: The Great Pyramid of Agile, Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong, Agile: Anatomy of a Failed Project, A Scrum Project That Failed.)

The fact is that seasoned business and IT leaders, particularly those at larger businesses, should take a closer look before plunging in to the Agile world with reckless abandon. Agile has a number of weaknesses that many disciples of Agile fail to acknowledge. After all, they’re in the business of developing with and helping you to adopt Agile, so they’re not likely to tell you about its problems and limitations.

Together with my friends and fellow associates at Cedar Point Consulting, we’ve come up with this list of Agile weaknesses, which apply to Agile as it is most commonly implemented:

  1. True Agile is rarely practiced. Long-time practitioners will tell you, “It’s Agile – not agile”. Without a doubt, the biggest single problem I have encountered in Agile-practicing shops in the past decade has been that too few people truly understand and practice Agile. In many cases, software developers, development managers and consultants alike mistake Agile for its lowercase sibling, agile, and assume that Agile is all about flexibility and absence of process.This is far from the truth. Agile has formal rules and structure, though they are quite a bit different from those of other development approaches. Agile is iterative, it is adaptive and it is supported by some outstanding tools and techniques, like burn-down charts, product backlogs, user stories and stand-ups. Most important, Agile is not anarchy. It does not mean that everyone does whatever they want and there’s no sense of organization, despite the fact that you may feel this is the case.
  2. Heavy customer interaction is essential. Reflected in principles four and five of the Agile Manifesto, heavy customer interaction is one of the biggest benefits of Agile, but it also becomes a weakness in some environments. Consider, for example, situations where the customers or users of the software being developed do not have the time available to meet with members of the software development team on a frequent basis? What if the key customer is the CEO, who often has more important matters to address? What if you’re not permitted to talk with the users?One important thing to know about Agile development teams is that they are high maintenance – they work quickly, but they also require much more time and attention from the business side to be able to work quickly. If that time cannot or will not be spared for their benefit, using an Agile approach will bring little gain over a Waterfall approach.

Click here to read the rest of this article on Cedar Point Consulting’s web site.


Interested in other articles like this one?  Read “Departing Waterfall-Next Stop Agile” and “Toward a More Robust Agile“.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in process improvement, project management methodologies and technology strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

%d bloggers like this: