Maximizing the amount of work not done in Agile? [duplicate]

Question

Here's a quote from "Agile Principles, Patterns, and Practices in C#" By Micah Martin, Robert C. Martin

10. Simplicity the art of maximizing the amount of work not done is essential. Agile teams do not try to build the grand system in the sky. Rather, they always take the simplest path that is consistent with their goals. They don’t put a lot of importance on anticipating tomorrow’s problems; nor do they try to defend against all of them today. Rather, they do the simplest and highest quality work today, confident that it will be easy to change if and when tomorrow’s problems arise.

I really don't get that.
Does that means, instead of building a robust main engine which will be able to handle the features needed, one should just build one feature right ahead?

Because as far as I know this would most likely eventually turns out inefficient and less flexible.

Let's take an example:

Imagine ASP.Net without base Control/WebControl classes, because the .Net dev team would just have rushed doing "TextBox", "CheckBoxe", "Label", etc. immediatly. The .Net team dev would have taken the simplest path.

Woudln't that have made the whole framework's developpement a hell of trouble?

Can somebody tell me if I got the quote wrong of it's a really debatable rule?

Answer 1

The concept of agile is that things change. So if you spend a very long time working on a super-engine, by the time you've finished and its ready to use, the requirements or technology may have changed and you'll have to start over.

In reality that's not likely to happen, but the requirements do change. So agile methodology works on the principle of getting something running and modifying it to make it fit, evolving it to be what you want.

Now this may sound dreadful, forever refactoring and never finishing (and some people do work like that, unfortunately) but if you have any experience then you'll be working on a design that can cope with a certain amount of change when you create the limited, initial releases.

ASP.NET is a bad example of up-front-design given that it is currently on release 6 and each version is very different to the other releases!

Its possible that you need experienced people in order to work efficiently in an agile way, or that experienced people will respond much better to agile than waterfall developments.

Answer 2

To use your .NET analogy, the flow for an agile development of those controls would be:

1. TextBox: This text box is pretty awesome!
2. CheckBox: Hey, another one, wait a minute...
3. Label: Yeah, I'm seeing a trend here
4. BaseControl: That helps!

Essentially, instead of up front trying to look for your abstractions and designs, allow the design to emerge as you go. It's not that you aren't focusing on building quality software, it's just that you should not be trying to waste time predicting what you'll need and building up frameworks and abstractions until you actually need it.

Answer 3

There is some room for debate, but I think most people agree on the gist of it.

simplest path that is consistent with their goals

Simple is relative to the goals. A prototype for the .NET concept may have been built the way you described, but at some point, the goal involves a major framework that needs to be built with a lot of rigor and room for expansion. In agile development, the mess gets recognized much sooner and you go back to the drawing board.

they do the simplest and highest quality work today

So when the goal is a "robust main engine" that's what you start to build. And you'll probably build it one piece at a time. If you're agile, you build something that works every 2-4 weeks and repeat.

Simplest doesn't always mean simple. Your client may have delusions of being the next Facebook, but when you look at their budget, you either adjust their goals and build something not quite so scalable or start building a grand website and not get paid for it.

Answer 4

Agile doesn't necessitate an absence of high level design. Before a story can be worked on by a developer, is a single user story going to completely capture everything needed to be defined before one can start sprinting?

As a user, I need to enter first name into a text input field on the X form, so that I can submit my first name as part of my profile information

One couldn't just start sprinting on this in a vaccuum.

• What language did we decide to use?
• What are the coding guidelines I should adhere to?
• What are some use cases that I can test to?
• Is the project skeleton and organization madeup?
• How are software components organized? Is there a component diagram describing the software component interactions?
• Should we follow Transaction Script pattern on the server side or Rich Domain Model/MVC?
• Did we create the Domain Model?
• What are the non-functional requirements? How quickly should I get a response back? What about security? Should I do XSS filtering and sanitize inputs?
• What are our database development standards? Do we have to adhere to certain naming conventions on schema objects? Is there a class diagram describing the user profile table?
• Do we have a framework established for proper unit testing of business logic?
• Do we have a proper development environment and testing environment built so that the story can be tested by QA in isolation of ongoing development changes?
• Did we implement Continuous Integration such that our builds are constantly occurring and being verified consistently.
• When the story has passed testing and is accepted by the Product Owner, do we have a Continuous Delivery implementation such that software changes can be delivered to other environments?
• Do we have source control in place with a proper source control and branching strategy decided on?
• What web frameworks and design decisions have we decided on? Angular? Spring MVC, JSON over REST services?
• Have User Interface guidelines been defined especially for how text boxes should appear?
• Have any common web components been implemented (or need to be implemented as part of this story) to properly deliver this story per the high level design and with the goal of minimizing technical debt?
• Anything else...

If you were just starting this one story, there is an infrastructure so to speak that needs to exist or you just bundle all of this complexity into this one seemingly small story. It is required for a story that should ideally be a tiny vertical slice of an entire system.

As a post office customer, I want to send an overnight package from my home in Boston to my friend in San Francisco.

The infrastructure that is required for this story is that we need a system of roads, a pickup truck, a mail sorting machine, an express airplane, an airport with a runway and traffic control, etc...

If it sounds like a lot then that is because it is. An enormous amount of work is necessary in terms of that development infrastructure that is required before one starts sprinting and directly delivering business value.

You really don't want to do this work in the sprint

There should be efforts before and between sprints to address and tune these processes and work.

Smoothing of Risk

The pursuit of minimum viable product and refactoring constantly to changing business needs is a smoothing of risk essentially. You could spend a lot of time developing a Cadillac solution for the business to turn around and say that they actually needed a boat all along.

Think of it as paying insurance against that disaster scenario. You spend two weeks and develop a skateboard. Then you spend another and develop and electric wheelie. Business decides they actually wanted a boat, you throw away your wheelie and create a paddle board in the next sprint. You are down and out the time spent on a useless skateboard and wheelie, but you prevented yourself from wasting a lot of time building the high quality chasis for a Cadillac.

Yeah it kind of sucks to work hard on something that will probably get thrown away in a month, but just remember,

It is not about the developer!

Your ability to work on kick-ass high quality beautiful software and have pride in your work is not guaranteed. It doesn't matter. The only thing that matters is what the product owner wants, and delivering working software with quick turnaround. That is it.