Simplicity the Art of Maximizing the Amount of Work Not Done Is Essential Agile Technique

When anyone of us was fascinated about "Agile" and started learning about it by trying to collect materials on internet, then Agile values and Principles in the Agile Manifesto appeared every bit a commencement outcome. And those iv values and 12 principles acts as a first footstep for us to start learning Agile. Gradually when we thought nosotros understood almost of them and move ahead to learn more than then get to know that Active revolves around those iv values and 12 principles but. If nosotros understood them well, so its not hard to prefer agile and go successful using this methodology. So we again come back to get more insightful of those principles. At least I did the same.

Then I was going through those 12 principles again and again, and convinced that I understood most of them thoroughly, except the ane continuing at 10th position. Though this principle has word "Simple" in information technology, I realize very presently that its most difficult to understand amongst all of them. Lets revise information technology once again:

"Simplicity — the art of maximizing the amount of work not washed — is essential."

After reading it, lot of things strike in our listen. Few of them are like what the hell "fine art" is doing in this technology field. And why only this principle is referring nigh fine art and not others. We are trying to make more and more complex things then why it refers about "Simplicity". Nosotros generally attempt to practice more piece of work. In fact it is the demand of this industry, demand from our direction and on that our functioning gets measured, and so why anyone will attempt or what is the necessity of "maximizing the amount of piece of work not done". And they are maxim it is "essential". Damn, its confusing more. Its not that unproblematic equally it looks from birds eye. Lots of things lies underneath.

Lets us apply incremental arroyo here to minimize this defoliation. We will move to next confusion later trying to resolve the start ane. Now lets effort to understand about the "fine art". Its called equally an fine art, because practicing this principle is an fine art and that one needs to truly master. While building product using agile methodology or lets say even with any methodology, as a team or individual, we take to make many decisions. In case of Agile, most important decisions are like valuing (prioritizing) the user stories in the production backlog, when to ship production in to the marketplace that is not fully adult and and then on.

Those decisions are taken based on instincts, ones understanding most product, market conditions, business demand and so many other factors. Yes, we have tools to aid u.s.a. about analyzing these factors, forming a patterns, getting reports from them but they works only till this point. They smoothing our work to take decisions but not taking decisions on our office. That's the job as a squad we have to finish. We accept to counterbalance reality in terms of time, technical restraints, upkeep and doing that is a kind of art and not science.

This principle also focuses on "Simplicity". In fact it is the existent essence of this principle. Flavors of agile like 'Scrum' believes virtually on this principle where we put everything 'Short and Simple' (kind of KISS Principle). In scrum, we accept simple task board to track the progress, requirements are described in simple user story format (As a < type of user >, I want < some goal > so that < some reason >), simple medium like 'Velocity' to calculate work completed. At initial iterations we tin also emphasized on shipping uncomplicated production with minimum functionalities those are piece of cake to use and to achieve Minimum Viable Product (MVP).

Like Scrum ane of the term used in Extreme Programming is "You aren't gonna demand it" (YAGNI) as well defines the simplicity. Traditional development method asks to proceed both eyes on future and do coding as per it for reusability. Whereas XP says to do it whatever require now and that too keeping it uncomplicated. Instead of both eyes, its similar merely keeping one eye on time to come and other to concentrate on present. We do many boosted things apart from what is needed at this moment presuming that they may be used further downwardly the road. But we may never walk on the route nosotros presume and any piece of work done at this moment keeping both eyes on that route becomes waste.

Then comes the discussion, "maximizing the amount of piece of work non done". Here Agile Manifesto developers would like to distinguish between the work that adds value vs the work done to produce features that is barely used. We tin employ 'Pareto Principle' or "80/20 dominion" here in many ways.

Firstly, it is about the features of production used vs their cost. Every bit per Standish Grouping 2014 survey most Exceeding Values, just 20 % of features of the Very Loftier to High Value projects are mostly used by customers . Hither value of project is measured on "Triple Constraints" i.e. Cost, Time and Scope. Then from the commencement pie chart shown below, we get to know that but 40% of projects delivers Very High to High value. Second pie chart convince united states of america that only 20% features of those high value projects are used more 'Frequently'. We can apply this survey to any projection/product. Just accept the example of cell telephone or digital SLR camera we take, which consist 100 of features but the most ofttimes used by us are hardly few. Even so they are there. Other significant of it is that those projects spend nigh of their Toll, Fourth dimension to deliver 80% of features which have depression to no value.

Secondly it is nearly, results vs efforts. fourscore% of our results may actually come from just twenty% of our efforts. The idea is to focus on the important twenty% of effort that gets the majority of the results. Considering speed-to-market is important then deliver the mostly used 80% of features in just twenty% of the time? Equally per great management consultant Peter Drucker, "There is cypher and then useless every bit doing efficiently that which should not be washed at all." Information technology teaches u.s.a. to focus more on work that is essential to create value to customers and ultimately to project.

Now consider above cases from the product owner perspective who actually decides what features should be built in to the product. This we can reach by having the skill of identifying the work that is not suppose to do and then ultimately reaching to point where nosotros can maximize those work. It can be done by identifying whether said features are "must-have" or merely "nice to have." Once we arrive at a list of must-have features, we can easily put all the nice-to-have features into the "piece of work not washed" bucket.

Feeling more in the "work not done" bucket, helps to nail down the truly valuable features that deliver the highest concern value. This principle reinforces Jeff Patton'due south communication to minimize output and maximize event. Information technology means that that we need to concentrate on the features that would help the client appreciate the "outcome," which ultimately may take no correlation with the number of features produced by the "output" (Evolution Effort).

But again its not like shooting fish in a barrel to take the decision near selecting and moving features to not doing bucket. As for different pale holders, different features look important. But we can accomplish to understanding point by using any of the prioritizing techniques. So, along with moving features to "Washed," information technology is also essential to create a listing of features that are not going to be done at early stage of development , irrespective of fourth dimension and resources constraints.

Keeping these things in mind helps u.s.a. at every stage in production development. In real earth, for most of projects it happens that because of time constraints team has to remove virtually of items from excess. At the later stage like this, decision is taken just considering the time required to develop those features rather than value of information technology. This chaos tin can be avoided past following in a higher place Active Principle from kickoff of projection.

At terminal I would say this is something I understood about 10th principle based on my feel while working in projects post-obit Agile Methodology, dealing with such customers and trying to deliver best to them using information technology. Identifying what is needful and 'must have' vs 'should have' depends on nature and context of project and many other things. And so following certain practices like TDD or BDD in one project may be overhead for some pocket-sized project.

And then we have to chief the art of deciding wisely while applying this principle.

congdonancentiond.blogspot.com

Source: https://www.linkedin.com/pulse/simplicity-art-maximizing-amount-work-done-essential-amol-sande

Share this post