In my last post I began talking about the Agile principle of simplicity (“Simplicity – the art of maximizing the amount of work not done – is essential”) and the approach that salesforce.com founder Marc Benioff advocated for building their software, “fast, simple, and right the first time.”  I wrote about the hard work of pursuing ‘simple’ solutions given all of the complexities involved and ended by asking whether it is even possible to do things fast, simple, and right the first time.  I want to pick up on these same ideas here in the second part of my thoughts on simplicity in Agile.

In my experience, Agile is well-designed for speedy software development.  Intentional short sprints that focus on delivering the next most important piece of valuable software to the market can result in phenomenal progress over time.  Over the past two years I have been regularly astounded and gratified by the volume of fixes and features produced by the two development teams I have served as a product owner.  A key part of what makes the progress of these projects feel so fast is that the teams are actually building something we know the market wants and they are doing this based on well-articulated and effectively -conceptualized user stories that provide the best balance of specificity and flexibility for the developers.  Of course, the fact that we develop something good quickly doesn’t mean that we don’t continue to iterate on it; we get a good product fast but over time we continue to enhance it as long as the market values our increased investment in the product.

Agile supports a simple approach to development not just in principle but also practically.  This is in part because of the focus on building only what we want and nothing that we don’t.  During the product discovery phase the product manager specifically and the development team more broadly works to hone their understanding of the minimum product or feature set that people will value and pay for.  When that has been defined the team works to create this product, scrupulously avoiding unnecessary add-ons that the market won’t value.  Products and features do not get built just because one client mentioned them or a developer things they would be cool or a product manager feels excited about them.  Agile pursues simplicity by maximizing the amount of work not done – and that requires strict focus on building what the market values.  Of course, the process of discovering and building the ‘simple’ solution involves lots of complexity as I mentioned in my previous post.

At first glance the idea of building things ‘right the first time’ might sound antithetical to Agile with its strong emphasis on iterative learning and product evolution.  How can you value getting things right the first time when you also welcome changing requirements at any point in the development cycle?  Part of how this comes together, as I said above, is that the product manager and designer do a fair amount of work before anything gets built defining what ‘right’ means.  Understanding what specific users will want and what feature sets a targeted market segment will pay for makes it much easier to build the right product the first time instead of wasting time building and releasing the wrong thing.  Iterations happen with prototypes which require a much lighter development commitment; once the team has identified an effective solution to a pervasive market problem they can create the right product ‘the first time’ and further enhance it through later iterations if necessary.  And Agile teams often ‘pivot’ in their development, changing directions rapidly as they respond to new market intelligence.

Agile’s commitment to simplicity fits well with the salesforce.com goal of building their software, “fast, simple, and right the first time.”  I am a huge fan of simplicity, deeply convinced that the art of maximizing the amount of work not done is much more important in being truly productive than trying to do more.  Here’s a recent link I found that talks more about the links between simplicity and productivity: http://linkd.in/12c44MI.  I resonate with this principle of Agile for the way I live my life and not just the way I approach software development.  Finding the truly simple way to do something often takes hard work, but the result is generally cleaner code and better products that are easier to maintain and enhance over time.  Taking the Agile path of simplicity might sound more complex than following the thoroughly documented road of waterfall software development, but looking back on the journey of creating truly great products allows the benefits of relentlessly pursuing simplicity to shine.  Even in the rapid pace of Agile sprints (or of daily life), this extra effort to find simple solutions and avoid unnecessary work pays dividends.  Of course, in truth it’s not that simple.