Align IT and Business in an Agile Manner

Agile Software Development

Subscribe to Agile Software Development: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Agile Software Development: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Agile Development Authors: Jason Bloomberg, Liz McMillan, Derek Weeks, Flint Brenton, Elizabeth White

Related Topics: Agile Software Development, XML Magazine, SOA & WOA Magazine, mHealth & H-Cloud

Agile Development: Article

Why Is Agile Development Hard?

Why Is Agile Development Hard?

I bet you thought agile development was supposed to be easier than a traditional, prescriptive process! That I would wax evangelical that agile development is the answer to everything, and it simplifies your life. Yeah, just like UML and model-driven architecture and XML and SOA and Web services are silver bullets. Uh-huh, r-i-g-h-t.

If you aren't familiar with agile development, you can check out our manifesto here: www.agilemanifesto.org/. You can also learn more here: http://en.wikipedia.org/wiki/Agile_software_development. The difficulty with "agile development" is that it is "in the eye of the beholder." That is, even a highly regulated, constrained application can be conducted in an agile manner. That manner will be radically different from the way a five-member team might approach building a small desktop software product that they want to sell. Both projects can be agile, and therein lies some of the issues that make agile seem "hard."

Why, then, is agile development hard?

It might not be so much that agile development is hard, per se, depending on your perspective. The reason I give for agile development being more of a challenge for many teams is simple:

YOU HAVE TO USE YOUR BRAIN!

No, I don't mean to infer that you don't normally use your brain. However, in a highly prescriptive process, it is easy to fall into a trap of doing an activity because... well, just because! Typical reasons are that a specific set of steps are mandated by a process, possibly making sense in some projects, not in others. But often, the process grows old, people no longer remember why they are doing a specific task, but do it anyway. Folks get comfortable building some document without ever asking the recipient if it is enough, too much, useless, perfect.
- Don't Mistake Activity for Progress

Developers often jump into the fray by "cherry-picking" specific fun stories and sometimes missing the big picture. For an app that needs to message another app and then do some crunching, I have seen developers working on everything but the core system development needs: the messaging or shelling out of one app to speak to another app. When I asked if they got the basics working yet and are now discussing the pretty frills, they looked around, kind of sheepishly. "No, we don't have the parent app able to message our part yet." If you use your brain and step back a bit, you can see that nothing else matters.

Despite making progress on "stories" they actually had no meaningful progress. Remember, if you can't see it working, it doesn't exist!
- Show Me Working Features

Yeah, yeah, yeah, I know, someone didn't prioritize the stories properly. But, you certainly cannot expect a "customer" to figure out that some weird technical messaging thingy had to be in place first. The customers better only talk about the business and features that are (generally) devoid of technology words.

Development teams have to think more broadly than just coding. If a team understands that the client needs to know about some aspects of the technology that have to be implemented before anything else matters, this should be brought to their attention.

Development teams also need to help with the project management aspects. Yes, that's right. You need to learn how to say "No!" - in a gentle manner, of course.

"So, can we add some more features to this iteration?"

"Uh, since we are three days to iteration 'pencil's down,' let me think. NO! It has to wait until the next iteration."

After all, if you know in your gut that there is no way for a disruptive request to be accomplished, why bother trying? You should always maintain your iteration delivery schedule, slipping features instead of dates. You should always maintain your good habits. Someone has to be the adult ;=)
- Learn to Say "No"

In agile development, you (and everyone else) are charged with the rather difficult responsibility of always challenging yourself to ensure you are doing the smartest thing possible that will bring about the best solution for the current project (and within its context).

You need to set up your agile team for "running fast" through each iteration's features. To start with, I like to model the problem domain to enough of a level of understanding from which:

  • Requirements/features can be written using a consistent language
  • Enough of an object model exists to anchor the coding
  • Enough complexity has been uncovered to make the cost/time estimate defensible
In addition, you need to understand the architectural approach (not to mention coding guidelines). You can slowly arrive at the ultimate architecture and call it refactoring. But at what cost? I like to get the bulk of the architecture design/building work out of the way before starting the first iteration. Of course, for some apps, you may already have the architecture style predetermined.

I like to ensure the team can hit the ground running with a list of features in hand, architecture, coding guidelines, automated build scripts, and a domain model from which to hang code.

Sure you can discover all of this piecemeal as you go along, but that is usually slower and less efficient than doing some work up-front to lay the groundwork. No, I am not talking about "Big Stuff Up Front" (BDUF/BRUF) type of an approach. I am talking about using your brain. Do enough up-front work to enable running fast (even with scissors). Maybe: Just Enuf Design Up-front (JEDI - if I substitute "Initially" <g>).
- You Must Lay the Proper Groundwork to Be Agile

By a few iterations in, if you are not ripping through the feature list/user stories almost faster than they can be compiled, you are not yet performing at a truly agile level. If it is "disruptive" that a customer changes the stories scheduled for the next iteration because of changing priorities, you are not yet performing at a truly agile level. If you and your team are not constantly using your brains, you are not yet in the agile state of mind.
- Agile Is a State of Mind!

Post any comments on my blog: www.compuware.com/blogs/jkern/

More Stories By Jon Kern

Outspoken software engineering evangelist, Agile Manifesto co-author, speaker, and author, Jon's experience is wide-ranging across varied problem domains and technology platforms. From jet engine R&D (he's an aerospace engineer, after all) to real-time flight simulator design and development, from TogetherSoft's and OptimalJ's commercially successful modeling tools to building IBM's Manufacturing Execution System software - Jon has seen and done a lot in his 20 years. Peter Coad recruited Jon in September 1999, to help launch TogetherSoft. Jon was a driving force behind the success of the company and its products prior to its sale to Borland. Jon's a nut when it comes to modeling effectively (focused on the business), building and architecting consistently, and doing it in an agile manner to deliver results. If a team ignores these best practices, it invites the peril of building up Technical Debt, as he likes to refer to it. Jon is a speaker that engages the audience and has fun doing it.

Comments (5) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Infernoz 07/25/06 08:32:26 PM EDT

ROTFLMAO, agile, really! Most of the projects I have worked on are not neat with well behaved customers who provide everything you need promptly, half the time they can't even make up their minds about critical details, in those situations agile is just wishful thinking! IMHO RAD, with lots of patience, political smarts, persistence, good domain frameworks, knowing when to refactoring work and the help of experienced staff works loads better. Stories have no place in business and coding, adaptable architecture, design and tasks do.

CZL 07/25/06 04:54:28 PM EDT

Good Article.
Althought I know by saying this, it will generate lots of noise from Xp/Agile camp, I will still take one step futher - Xp/Agile is excellent for and only for prototypes.

Imagine that runing Agile/XP in a development team in a production system, you change the db schema or published wsdl interface in each iteration. Think about DB migration effort and the clients development effort to adjust to your wdsl changes. Will that ever hold?

I undertand that XP/Agile is trying to address the over-design issue and avoid the major pitfall that legacy water fall appraoch is facing. However, it creats or magnifies its own problem.

To my experience, XP/Agile works out good in the inital phase. Then after 1st or 2nd iteration it starts degrading fast - many of the "little" changes requires more and more refactoring effort as the process carry on.

CZL 07/25/06 04:54:21 PM EDT

Good Article.
Althought I know by saying this, it will generate lots of noise from Xp/Agile camp, I will still take one step futher - Xp/Agile is excellent for and only for prototypes.

Imagine that runing Agile/XP in a development team in a production system, you change the db schema or published wsdl interface in each iteration. Think about DB migration effort and the clients development effort to adjust to your wdsl changes. Will that ever hold?

I undertand that XP/Agile is trying to address the over-design issue and avoid the major pitfall that legacy water fall appraoch is facing. However, it creats or magnifies its own problem.

To my experience, XP/Agile works out good in the inital phase. Then after 1st or 2nd iteration it starts degrading fast - many of the "little" changes requires more and more refactoring effort as the process carry on.

CZL 07/25/06 04:53:15 PM EDT

Good Article.
Althought I know by saying this, it will generate lots of noise from Xp/Agile camp, I will still take one step futher - Xp/Agile is excellent for and only for prototypes.

Imagine that runing Agile/XP in a development team in a production system, you change the db schema or published wsdl interface in each iteration. Think about DB migration effort and the clients development effort to adjust to your wdsl changes. Will that ever hold?

I undertand that XP/Agile is trying to address the over-design issue and avoid the major pitfall that legacy water fall appraoch is facing. However, it creats or magnifies its own problem.

To my experience, XP/Agile works out good in the inital phase. Then after 1st or 2nd iteration it starts degrading fast - many of the "little" changes requires more and more refactoring effort as the process carry on.

Juan Bernabo 07/25/06 11:06:31 AM EDT

I think Agile is harder becase it needs more leadership skills like pro-activity vs. reactivity, having a vision, sense of what is more important, needs more discipline, needs an synergistic aproach, win-win mindset, and more comunications skills.

Have you read the 7th Habits of Highly Effective People from Dr. Covey? This iss a must for Agilists.

Juan.