DZone
Agile Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Agile Zone > Becoming Agile: The One Change

Becoming Agile: The One Change

James Sugrue user avatar by
James Sugrue
CORE ·
Jul. 26, 10 · Agile Zone · Interview
Like (0)
Save
Tweet
10.89K Views

Join the DZone community and get the full member experience.

Join For Free

For some of us, taking an Agile approach to software development is easy. But for others, particularly companies who are established in a waterfall based approach to software development, embracing agile can be much more difficult. Anders Ramsay recently blogged about Agile UX and The One Change That Changes Everything, which gives some really useful advice on how to start your journey down the agile road.

What I really like about the article is that it emphasises that one simple change can trigger the agile mindset. According to Anders, that one change is "Just Enough Design Up Front", in contrast to Big Design Up Front.

For a lot of readers, this change in mentality might be obvious, or might be something that you've been doing for years: iterative development. But in practice, is this really the truth? Doing some level of design up-front makes a lot of sense, whether that's user interface design, or code design. I think that what happens all too frequently is that we add too much to the design. Too much time is focussed on questions like "What if the app needs to do this", rather than just getting the app to perform it's core functionality, and build on the design from there. The Big Design Upfront approach is appealling because we believe we're insulating ourselves from big refactors down the road. But maybe the "what if" case will never happen.

I really like the approach that Anders puts forward. It encourages more communication at design time thoughout the entire team. A big picture design is put together so that a system view is available to the team early on. The detailed design gets elaborated on throughtout the development process.

I'm sure there are many companies who have had success with non-Agile approaches. For those companies, unless agile can provide significant improvements in productivity, there's probably no reason to fix something that isn't broken.

For those who have successfully adopted the agile approach, what was the one change that changed everything in how you develop software?

agile

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Test JavaScript Code in a Browser
  • 7 Traits of an Effective Software Asset Manager
  • Choosing Between GraphQL Vs REST
  • Synchronization Methods for Many-To-Many Associations

Comments

Agile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo