Epics and Features are higher level containers. User Stories and Tasks are more sub-level components.

• Epics can DIRECTLY be broken into User Stories/Tasks (aka backlog items)
• Epics IDEALLY need to be broken down into Features.
• Features can be broken down into User Stories / Tasks / Backlog Items. These tasks / stories are what fit into SPRINTS.

How to add a task to an Epic?

From Epic –> Add Link (Task or User Story). Fill in the details.

Where does a backlog item fit in?

Typically, a backlog item is a task that belongs to a Feature (or directly to an Epic).

The post Azure Devops – Features, Epics, User Stories and Tasks appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Only XP is suited to deliver this use case. Test Driven Development ensures that features are constantly tested against legacy system functionality.

The post XP versus Scrum appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Physics gone astray

  Theoretical Physics has gone astray. Ask any practicing physicist today and they will lament about the burgeoning number of contending versions of string theory, all promising grand unification.  Even as one version of the theory is being experimentally ‘validated’, another one crops up, promising to be a better, shinier version of the previous one.  Except, the Universe had other plans. It continues to expand, as was recently, experimentally proven. This expansion implied a positive cosmological constant, which was something that string theory had failed to predict. Yikes….30 plus years of grinding out ungodly math, and we are virtually back to the drawing board. 

Ironically, string theory set out to UNIFY all the fundamental forces of physics. One grand theory to try and explain everything in nature. Except, what emerged from string theory was a total of 10 ^ 500 possible theories!  Double Yikes!

What does this have to do with Agile?

Today’s Agile landscape suffers from the same problems as the String Theory landscape  – too many flavors, and not enough experimental proof that any of those flavors actually work.  With a new Agile flavor appearing every year, and promising to be the ultimate dev methodology, one is led to ask the question – Has Agile gone Astray? 

This post will dissect some of the leading Agile methodologies (notably Scrum and SAFe). The author makes the following claims (and narrates real-world, coding snafus to support these contentions):

1. The aspects of Agile that work well, have existed long before the advent of Agile XP/Scrum.  Some of these practices made it into Agile (especially XP). It is pointed out that any improvements that Agile seems to deliver, have to do with these common sense practices.
2. Certain Scrum practices, not only fail to improve the quality of release code,  they actively interfere with producing rock solid  code.
3. The hidden costs of doing Scrum, for small or large teams, are often ignored.  Scrum costs small dev teams upwards of 100k / year, without delivering any tangible benefits.
4. Anyone, and I mean anyone, can become scrum certified. Whether they have ever seen a line of code or not. The Scrum Alliance has become an organization that hands out certificates rather than ensures quality of their graduates. You can get a ZERO – that’s right – a ZERO on the certification exam – and still get your certificate. 

Common Sense Coding Practices

Constant Customer and Team Involvement, Testing your code before it gets to production (unit testing specifically) are all part of common sense coding practices that actually existed well before Agile (though Agile XP did a good job of enforcing these). 

  Code quality is not a result of any development methodology, but is more a function of common sense coding practices. These include practices such as code and design reviews (existed before Agile), unit testing (also existed prior to agile) and static code analysis.  Sprints, Daily Scrums, Coding Only to Current Requirements are all Agile tenets that actually degrade code quality. You read that right – these practices are not just unhelpful, they actually produce unstable, haphazardly released code. 

Agile, in it’s modern day incarnation (aka Scrum or SAFe), does little to ensure the success of a project. If success alludes to code quality, fewer defects, and mapping to actual customer needs, then Agile Scrum , Agile SAFe and all related embodiments are actually headed in the opposite direction. 

So where and how exactly did Agile start going astray….?

Agile Misguided Tenet # 1 –  A daily status update (scrum) is required to make the team more productive…

Does the sales team in your company stand up every morning and go around informing each other about what they will be working on today? Does the management team do something akin? How about the H.R. team? Or the graphic design or creative writing team?

The answer, of course, is a resounding NO !

Not because these teams are lazy or unmotivated, but because :

1. These teams have learnt how to communicate and get results without having to constantly advertise their day to day work schedule. 
2. Selling, graphics design, Management are all art forms. To provide a regimented approach to an art form only stifles it. 

Well, guess what?  Coding is as much an art form as any other endeavor, believe it or not.

Why do coders (or coding managers) feel that a regimented approach will produce better code? How did this ‘daily stand up’ practice start to begin with? 

  I believe that part of the motivation was the high failure rate of waterfall based I.T. projects, and the belief that somehow fixing developer practices would result in a higher success rate.  Not only did Agile NOT make projects more successful (see references at the end of this post), this article will argue that recent Agile practices, accomplishes the exact opposite. The success rate of Agile projects has not changed drastically from the waterfall success rate – but I do believe that most Agile teams today churn out unfinished, half-baked code.

Agile Misguided Tenet #2 – Code at the end of each sprint needs to be production ready

Solid code needs at least 3 iterations. For me, this means, write working code, write the test around it – check it in and go home (Iteration 1). Come back the next day (having slept on it) , rework it,  improve it’s readability somewhat  – and check it in (Iteration 2). Now, a week later, having forgotten all about this code that I wrote a week earlier, I am hit by inspiration (why did I use a switch statement when I could have used the strategy pattern instead??).  Having been struck by lightning, I race frantically in the middle of the night, log into my workstation – and completely rework the entire method that I wrote a week ago.

Of course, the original unit test breaks, and needs to be rewritten as well.  All this happens a day before the end of the sprint (which, remember, is meant to be production-ready code).

Now, I actually go to bed peacefully realizing that my code is in the final state that God intended it to be.  No more spaghetti, no more outdated, kludgy switch statements. All that remains is  an elegant OO pattern that could be easily extended to accommodate more switch cases. Both me and my code are resting peacefully.

The next morning, the scrum leader isn’t at all happy.   Why did I make these massive code changes the day before code freeze?  After all, my previous code was working just as well, as were the unit tests around it. Why did I feel the need to change everything the day before the code lock?

So, I  have to spend time convincing the Scrum Master that all code is really a living Work-in-Progress – like an unfinished symphony, searching for it’s missing notes.  Code just wants to reach completion, otherwise it feels discordant and experiences depression and internal turmoil . Needless to say, the SM isn’t buying any of this.

To get code to reach it’s final resting place, requires at least 3 iterations (ask ANYONE who writes code for a living).

And a 1-week or a 2-week sprint is usually not enough time to allow 3 iterations of the same code for the same stories.

Which is why, I claim, that most ‘Agile’ code is actually haphazardly written and half baked, in an unrealistic sprint to an imaginary finish line.

Agile Misguided Tenet #3 – Only Code to the current set of requirements (a.k.a – shortsightedness )

The case of the long running SOAP service

One fine day, I wrote a SOAP client that performed a background check on a loan applicant (against several external java web services). The external service took forever to return, at times, and so, the requirements asked that the client retry the process, in case it failed the first time.  Fair enough. In my mind, this could be accomplished easily with TWO configurable switches.

1. The first switch is obvious – how long (seconds) does the SOAP client wait before retrying?  No disagreement from anyone here.
2. The second one, that some of my team members were not fully on-board with, is the NUMBER of times you retry.  The original requirements only asked for a SINGLE retry.  And if that single retry failed, we just gave up and moved on to the next applicant’s background check.

I decided that this second number needed to be made configurable as well (with the default set to a SINGLE retry, so we were compliant with the original requirements).  And I coded that into the final version of the code.

As it transpired, a couple of days after we released our code, the business group threw a fit as to why so many credit applications were ‘failing’ and why were we not retrying more often?  Our team’s muted response that ‘we were only asked to retry once and then move on…..’ fell on deaf ears.  After all, this was seriously hurting business. And we did not have the time to go through a code fix and an entire release cycle!

Needless to say, I came out looking like a bit of a hero when I informed them that we could easily fix this, WITHOUT deploying any new code!  (since, I had made the number of retries configurable as well).  Had I stuck to the letter of the requirements, Agile would have not approved putting in that second switch.

The case of the method that needed to be overridden

  I am writing a new class with a few core methods (e.g. a Custom Authentication Class). Some of the core functionality in those methods MIGHT need to be overridden, even when there were no requirements that said so. 

So, I would mark the core method as virtual, provide a default implementation in the virtual method and let the inheritors of the class decide if they wanted to use the default functionality or write their own.

Again, Agile would not necessarily approve of my approach here – that some requirement in the future might need to do something, so let me code it in here to begin with. Once again, Agile would be shortsighted.

  I am simply illustrating that we need to let COMMON SENSE, and not Agile, dictate the depth of software that gets written.  If you are coding an important feature (story) that you think might change (based on your common sense), you need to accommodate that potential change into your code right there and then, instead of waiting till the worst case scenario happens.

Accommodate it regardless of whether Agile demands it or not, because common sense is more important than Agile. You are not necessarily violating the original requirements (as illustrated in the examples above), but you are also ‘future’ proofing your code (something that traditional Agile frowns upon).

Agile, by focusing only on the literal aspect of written requirements, misses the forest for the trees.  It asks developers to Put common sense aside and code only what is currently asked. This abandons all hope of future proofing code’ . And believe me, there continue to be drastic consequences of this short-sighted vision of Agile. 

The case of estimating a coding task and estimating OTHER people’s coding tasks

Scrum notoriously relies on estimates for tasks that developers are assigned. There is always a hidden level of complexity in any task, as any developer is aware. Sometimes, a task that looked like a 30 minute thing, becomes a 3 day grinder. And sometimes, the exact opposite happens.

Scrum forces you to come up with an estimate for something that, inherently, defies estimation. To make matters worse, Scrum expects you to anticipate how long OTHER people’s tasks are going to take! You don’t even know what you are going to wear to the party, but you are expected to pick out the right attire for the entire team!  

Agile Misguided Tenet # 4 – Scalable Agile ( SAFe ) can save your enterprise   

What happens when you take poor practices and scale them, horizontally and vertically, to encompass your enterprise?  That’s a rhetorical question…Seriously, SAFe (Scalable Agile Framework) promises to do just that. And it is (was) so addictive that I was truly mesmerized by it.

It promises the perfectly fine tuned enterprise, much like a humming Rolls Royce. Architectural Runways, Value Streams, Epics….SAFe sounded more like poetry, than software development.  The terminology used by SAFe was (is) beautiful.

And then it hit me. SAFe was still Agile! It was still the same bad candy, wrapped in newer, shinier wrapping paper.  As I delved a little deeper into each of the new SAFe constructs, I realized that they were not really new.

• SAFe Architectural Runways ? –  An architecture implementation in code that can be reused across projects. D-uh – we used to call this an application framework, and we used to write these for fun.
• SAFe Value Streams? We used to call them Product Lines (like MS Office, Exchange etc..)
• SAFe Epics ? We just called them ‘Releases’
• The list goes on….

There was nothing new here. And yet,  all the sexy talk around SAFe had really caught on.  Just like holding on to a live wire carrying current, I almost couldn’t let go.

Noteworthy Agile Tenets and Practices – Customer Involvement, Automated Unit Tests, Pair Programming

Not all that came out of the Agile revolution was terrible.  Increased customer interaction, Pair programming (an XP concept) and automated unit testing – are all powerful constructs that Agile popularized. And that is the key word here – popularized. It is not like Customer Interaction or Unit Testing were missing in the pre-Agile world.

Unit Tests, The Ultimate Code Detectives

I once had the unenviable task of merging thousands of lines of code (of a 3rd party UI library) with a newer version of the library. The problem was, that the old version (of the 3rd party library source code) had been heavily modified by our development team without any documentation. This meant, that when I merged (upgraded) to the new version of the library, I would have no clue whether the merge conflict was due to an actual feature that the upgraded library offered – or just some local change made by an in-house developer.  Trust me, it wasn’t fun.

Fortunately, I hit upon an idea that saved the day. What if I wrote unit tests around the older code base? That way, I would know what the expectation of each UI library component was expected to be, before I performed the merge. Then, after the upgrade (merge), even if I made a boo-boo, I could rerun my unit tests – and see if they still produced the same results as before. If they broke, I knew that chances were that a local developer change had occurred around that piece of code.  Right there, unit tests saved me about 3 months of tedious work.

The beauty of automated tests is that  they catch issues before they make it to production. They are like super detectives, catching the murderer even before the crime has been committed. By constantly scouring your innocuous looking code for breaking changes, they catch culprits before they make it to the release environment. 

Pair Programming, Two Pairs of Eyes are better than one

Pair programming is just another common sense concept – two pairs of eyes are better than one. As if that needs to be stated . But yes, Agile XP did promote this practice.

Customers, as part of the team

Agile did help popularize ‘regular customer interactions’ and, thus, deserves some of the credit for this common sense practice. Obviously, customer interaction was something that pre-Agile projects also tried their best to do.

However, once again, how much a customer actually interacts with a development team is never driven by Agile/Waterfall, but rather, by higher level intangibles.

These intangibles include budgetary constraints, existing customer relationship and of course, availability and level of interest of the customer herself.  Agile, by itself, will not bring your customer to the table. You have to bring the customer to the table. 

Unit Testing Existed Prior to Agile

Pair programming improves the quality of the software as does the writing of the unit tests. These practices improve the quality of the code internally simply by adopting common sense practices.  Writing code to test code has been around since the days of C programming language (those test programs were called ‘drivers’ – they ‘drove’ the test execution of the actual C program).

Still, Agile made unit testing popular and sexy, and deserves some credit.  However, as it turns out, unit testing is probably the most frequently ignored agile practice by Agile teams. Go figure…!

Agile (Scrum) Fails as Often as Non-Agile

What Agile evangelists forget is that the spirit of the (Agile) law always trumps the letter of the (Agile) law.  When we see a child stealing a loaf of bread, we do not arrest him and put him behind bars (even though the letter of the law demands that all robbers be punished).  We provide the child with some food and shelter and also, hopefully, some love so that they will not become a repeat offender.  All of civilized society is based on following the spirit, rather than the letter of the law. The letter is usually just a piece of paper; the spirit is what equates to the ‘common sense’ interpretation of the law. Common sense tells us that not all loaf stealers are to be treated the same. Common sense tells us that not all killers are equal (someone who kills in self-defense is usually considered a hero, not a murderer).

Scrum practices, by focusing on the letter of the law, tend to defy common sense on a regular basis.  Agile project take-offs, with their fancy architectural runways, crash just as often as other non-Agile projects. What gives?  

Coding is an extremely demanding and individual art form, one that rejects regimentation. Daily Scrums, 1 week sprints are all antithetical to producing good, artistic code.

Surveys that have compared waterfall projects to Agile projects have concluded that the failure rate for projects is about the same (yes, agile has a slight edge, but I believe that has to do with the few ‘common sense’ aspects discussed above).

I.T. Projects fail for much bigger reasons which include, but are not limited to, budget crunches, employee turnover, competitor  products etc. 

However, I believe Scrum goes a step further and encourages failure by trying to haphazardly sprint to an imaginary finish line, compromising on the quality of the code in the process.

The  Scrum Alliance, Even my plumber (no offense to plumbers) can get certified!

The Scrum Alliance is a non profit organization that charges $1.5k for handing you the title of CSM (Certified Scrum Master). I use the word ‘handing’, because you are given the certificate regardless of whether you pass or fail.  If you want to become a CST (Trainer), the cost if $5k.  I am not saying that the organization isn’t legit, but merely pointing out that there’s a lot of money being made by both, the alliance and the people who get certified by the alliance.

The first issue here is that  –  a Scrum Master who scored 100% on the exam is considered equivalent to someone who effectively scored ZERO. That is bothersome in itself. However, the broader issue that I see is that this certification can be obtained by someone who knows zilch about coding or software development. Heck, if my plumber decided to get certified, all he would have to do is pay $1500 and get his certificate!

This disconnect between actual coding and SDLC experience and getting Scrum certified should bother companies adopting Scrum.

The Hidden Costs of Adopting Scrum

Scrum has a lot of hidden costs for your team that are often ignored.  Let’s assume a 5-person team spends 12 hours in meetings/scrum activities (panning poker, backlog trimming…).   That’s 60 man-hours every sprint doing this stuff. If the average pay is $40 per hour (about $80,000 / year), that’s $2400 per sprint that is spent on ‘activities’.   For 50 work weeks, that is over $100 k / year!

Since Scrum gives the ‘impression’ of promoting efficiency, these hidden costs are often ignored in light of the bigger picture.

Revised Agile (Common Sense) Tenets

So, without further ado, here are my revised Agile tenets:

• Anuj.com’s  Revised Agile Tenet 1 – Scrap the Scrum, Replace it with a 1-1 developer interactions
  • Standing up daily and announcing your progress does nothing to make your code (or your productivity) any better than it was yesterday.  That daily stand up is simply the letter of the Agile law. If one truly thinks about the spirit of the Agile law, one would be writing and rewriting the same piece of code till it was ‘just right’. No need to stand up or to announce to anyone that you were on the third iteration of the same story.  If you need to understand what someone else is working on, simply go speak to him/her 1-1.
• Anuj.com’s Revised Agile Tenet 2 – Code to Common Sense, not to a piece of paper
  • One would also be accommodating future changes into their code, even if such were not mandated by the current set of requirements. Because, common sense, often demands that make your code ‘future proof’. 
• Anuj.com’s Revised Agile Tenet 3 – Replace Sprints with Slow Jogs (to get truly solid, unbreakable code)
  • One should not be dashing to a sprint finish line – just so one could claim they had ‘releasable’ software every two weeks. Instead, one needs to actually write ‘releasable’ software, and this means software that undergoes several rewrites for the same pieces of functionality (the 3 iteration rule).
• Anuj.com’s Revised Agile Tenet 4 – Encourage and incorporate common sense coding practices, whether they are part of Agile or not.
  • Encourage common sense coding practices such as running static code analysis, code complexity tools, automated unit tests, pair programming, customer interaction, 1-1 developer interactions and such.

Teams that I have worked closely with have produced killer software, without utilizing Agile in any fashion whatsoever.  Software written back in the late 90s still works flawlessly on both Unix and Windows, even though Agile was just an adjective applied to fast cats (like the cheetah), back then.

The code our team produced was rock solid; and at least part of it had to do with the fact that we were not rushing to a finish line every week.

Where can I learn more ?

If your team is just getting it’s feet wet with Agile, Anuj.com offers a simple, no-nonsense approach to building Agile Teams.

For a broader understanding of the emerging technology landscape – what works, what doesn’t, what’s hype and what’s not,  register for our popular,   The Ultimate Technology Seminar for Executives (TUTSE ), Separating Hype from Reality. Seating is limited to 12 attendees. The half-day seminar covers trending topics including Cyber Security Risks and Mitigation Strategies, Data Analytics and BigData, Cloud Strategy for the Enterprise , Application Integration in 2017 and more…all presented through real-world success (or failure) stories.

The post Has Agile gone Astray? Agile meets String Theory appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Scrum is a popular implementation consisting of Sprints.

SCRUM sprints correspond to AGILE iterations.

Kanban – Introduces WIP (Work in Progress) to Scrum

You can apply Kanban principles to any process you are already running (even to Scrum ).

• In Kanban, you organize your work on a Kanban board. The board has states as columns, which every work item passes through – from left to right.
• You pull your work items along through the in progress, testing, ready for release, and released columns. And you may have various swim lanes – horizontal “pipelines” for different types of work.
• The only management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. By managing WIP you can optimize flow of work items. Besides visualizing work on a Kanban board and monitoring WIP, nothing else needs to be changed to get started with Kanban.

SAFe – The Reason for it’s evolution – 

The idea of cataloging a team’s complexities and having reusable patterns with which to solve them is a cornerstone of the Agile Scaling Model.

Lean versus Agile

Agile is a manifesto

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Lean comes from Lean Manufacturing – and explains the workings behind agile practices.

1. Eliminate Waste
2. Deliver Fast
3. Build Quality
4. Respect People
5. Create Knowledge

SAFe: Consists of Value Stream (Office, Windows…) –> Epics (Release Trains)  > Capability (Features) > Feature  > Story (Story) –> Task. These, along with Nonfunctional Requirements (NFRs), are the Agile requirements (system behavioral) artifacts that are used to define system and Solution Intent.

Stories – Are user stories (Customer creates new account) and enabler stories (create OO hierarchy for Accounts )

Iteration Goals are defined in terms of points and velocities. Typically a work day (8 hours) translates to 8 points (team points).  Start with a small story (say an 8 point story is small). Use that as the reference. Now, assign total points to the various stories and tasks in the iteration. Initial Velocity – Final Velocity. Revisit in the ‘Iteration Retrospective’x

SAFe – Lean

Simply, lean means creating more value for customers with fewer resources. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.

• Decentralize decision-making
• Help in building Agile Milestones and Roadmaps, as well as the building plans that enable them Help develop, implement, and communicate the economic framework.
• Participate in Inspect and Adapt workshops; support teams by helping them remove systemic impediments and implementing continuous improvement backlog items
• Protect teams from distractions and unrelated or unnecessary work Assist the Release Train and Solution Train Engineers with PI Planning readiness and Pre- and Post- PI Planning activities
• Participate in PI planning, System Demo, and Solution Demo Build partnerships with Suppliers, subcontractors, consultants, partners, and internal and external stakeholders
• Provide other resources as necessary for teams and ARTs to successfully execute their Vision and roadmap
• Reinforce the Essential SAFe practices Identify delays in the system by facilitating or participating in value stream mapping

SAFe Architectural Runway

is the existing technical infrastructure, instantiated in code, necessary to support the implementation of upcoming features without excessive, delay-inducing

SAFe Agile Release Train ( ART ) and Value Streams

Agile Release Train (ART) builds and maintains (or shares), a pipeline with the assets and technologies needed to deliver solution value as independently as possible. The first three elements of the pipeline work together to support delivery of small batches of new functionality, which are then released in accordance with market demand.

An ART can have multiple value streams

SAFe Stories		SAFe Continuous Delivery

SAFe Level of Complexity

• The highest level of complexity is called Agility@Scale (A@S)
• the middle level is his well-known Disciplined Agile Delivery (DAD);
• The lowest level of complexity is Core Agile, which is basically scrum.

SAFe Limitations

SAFe does not provide any guidance for a few of the other A@S factors—specifically, geographical distribution, organizational complexity, compliance requirement, domain complexity, and organizational distribution.

TOGAF versus Agile

• Agile’s mission includes individuals and interactions over processes and tools. EA ( TOGAF ) is all about the process.
• Agile – early and continuous delivery – constant customer demos. TOGAF – phases – but not necessarily demos at the end of each phase
• Agile starts where EA ends.  TOGAF is not necessarily waterfall
• TOGAF can add vision to Agile

Overlap between EA and Agile

• Iterative,
• Collaborative,
• Soft Skills 

ITIL versus SDLC (Plan, design, implement, test, improve)

IT Information Library it has supported the idea of the delivery of the IT infrastructure as a set of IT Services as opposed to the individual hardware and software components that make up those services. The right question is not which method or process framework to use, but rather how to integrate SDLC-enabled activities in support of systems development in the larger context of the IT Service Lifecycle.

The post Agile versus Scrum versus SAFe–Some notes appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Agility avoids disasters before they happen.  Two key aspects of agile development:

1. Software is in an always ‘releasable’ state (working prototype).
2. Test Driven development catches bugs before they make it out of the development environment.

Requirements change – even for projects that seem to be well defined and compartmentalized. It is impossible to predict the needs of the business – and any product is subject to last-minute scope creep. 

While no development methodology can avoid scope creep, Agile can reduce the impact it has on the final product. Loosely coupled software should be favored over monolithic, tightly coupled (all functionality in one code base) software.  While loose coupling is not a direct tenet of agile, agile, if practiced correctly leads to loosely coupled software.

The post The benefits of Agile Development appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

When I was a physicist (before I joined the computer industry), one of my favorite things was running lab experiments.  For a physicist, a simple experiment could prove (or disprove) something really deep. The experiment itself would usually be something as simple as rolling two balls – one heavy – one light – down an inclined plane – to see which one reached first (they both reach at the same time). But the underlying concepts that are revealed belie the simplicity of the experiment. They point to a deep realization about the equivalence of gravitational mass (the mass ‘m’ that appears in and inertial mass (the mass that appears in Newton’s second law ). There is no reason these have to be the same – it just turns out that they are.

When I started building software applications, a lot of times, I would write code for days on end without seeing the end result. However, with the advent of unit testing, I have re-discovered the experimenter in me once again.

A unit test is nothing but a small, controlled experiment.

You have a hypothesis, you write a test to prove the hypothesis. It either passes or fails (usually fails on the first attempt!). So – you try and figure out why it failed. And that calls into scope all your skills as a software developer. You often have to re-evaluate the piece of code your were testing – and (usually) rework a part of it. Then you go back – and re-run the test – this time, with a little more optimism. And you keep repeating the process above until your little, (no more than two-three lines of code) test – passes.

In other words, it is no different from performing a scientific experiment. And like the experiment, what the test reveals about your codebase, is anything but ordinary. Often times, unit tests reveal big, gaping holes in the original requirements. Things that fell through the cracks. Things that no one thought about. Things that would otherwise, have only been caught post deployment. It’s never too late to thank your unit tests for saving your application from a catastrophic post-deployment failure.

Summary

Unit Testing, is in my opinion, one of the greatest advances in software engineering in the last two decades. Yes – there was a form of testing in the olden days (C code would be tested through drivers that drove the code) – but never were the tools as sophisticated and advanced as today. In my world of .NET development, one is spoiled for choice when it comes to testing tools (MSTest, NUnit and MBUnit and NCover are some of my favorites). Agile is the rage of software development today. However, teams that are doing Agile – but not writing unit tests – might as well abandon the rest of their agile practices. The agility in Agile comes from unit tests – as I tried to describe in an earlier post. In addition to code resilience, unit tests bring a level of excitement (via immediate feedback) back into the software development process. Your thoughts, experiences?

The post Unit Tests are nothing but small, controlled experiments appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Definitions

• Agile – Software that adapts well to change (is well-designed and has comprehensive test coverage)
• Flat-Footed – Software that is NOT agile.

As I start work on my eighth Agile project, I felt it was time to take a breather and recap everything that I have learnt about Agile (the fact that this post just has 2 points to touch upon doesn’t say much about my learning ability! However, living by the maxim that quality trumps quantity, I plod on…).

The whole idea behind Agile is based on the assumption that all customers are ‘fickle’ (for lack of a better word).  This means that all requirements are subject to change (even the ones that are ‘locked down’). Not only can a customer change her mind (about anything) later, but the software must be tweaked/revamped as needed to accommodate the changed requirements.  I remember a poster from college titled:

‘Rules that Women would like to share with men’…

• The Woman always makes the Rules.
• The Rules are subject to change at any time without prior notification.
• No Man can possibly know all the Rules.
• If the Woman suspects the Man knows all the Rules, she must immediately change some or all of the Rules.
• The Woman is never wrong.
• The Woman can change her mind at any given point in time.
• The Man must never change his mind without express written consent from the Woman.
• The Woman has every right to be angry or upset at any time.
• The Man must remain calm at all times, unless the Woman wants him to be angry or upset.

Substituting ‘Customer’ for ‘Woman’ and ‘Developer’ for ‘Man’, here are the rules as applied to software development.

The Rules as applied to Software Development

• The Customer always makes the Rules.
• The Rules are subject to change at any time without prior notification.
• No Developer can possibly know all the Rules.
• If the Customer suspects the Developer knows all the Rules, he/she must immediately change some or all of the Rules.
• The Customer is never wrong.
• The Customer can change their mind at any given point in time.
• The Developer must never change his mind without express written consent from the Customer.
• The Customer has every right to be angry or upset at any time.
• The Developer must remain calm at all times, unless the Customer wants him to be angry or upset.

Ok – so the point of that little diversion was simply that the customer is always at liberty to change their mind (even for those projects where requirements are seemingly ‘locked down’ – such as fixed-bid type of projects).  Agile’s whole purpose in life is to handle any and every curve ball that the customer can throw at the development team. In the pursuit of Agile, I find two areas where development teams get the intent of Agile all wrong.

The two agile tenets that are most commonly misunderstood/abused are:

1. Agile Tenet 1: Only program the system to meet the current requirements

2. Agile Tenet 2: Write comprehensive Unit tests

Misinterpretation of Agile Tenet 1 – Only program the system to meet the current requirements.

Flat-Footed interpretation (misinterpretation) of Agile Tenet 1 : We can start coding anytime – even if some of the more critical requirements are not currently available.

Agile does not say that you should begin coding without requirements. Agile does not say that you should use the ‘start with current requirements’ as an excuse for not flushing out the important missing pieces up front. Agile’s intent here is simply to let you know that your system must be designed in a way to accommodate change. It is not saying that your system must be designed using an incomplete or inaccurate blueprint.

The simple example below may help illustrate this.

An Example: Building a simple contact form (web form):

Say you are tasked with building a simple contact form – just your everyday firstname, lastname, address fields, email etc. On the address fields, the customer is unsure about:

a) Whether they will allow a single ‘address’ for the customer or multiple addresses (e.g. Amazon.com)

b) Whether they allow a single contact per address (e.g. a typical consumer shopper) or multiple contacts per address (e.g. a business office location)

“Flat-footed approach” : Builds the system assuming a single address (instead of accommodating the possibility of multiple addresses) – and a single contact per address. If things change down the road, they anticipate that they can accommodate that change.

Correct Interpretation of Agile Tenet 1

  Answers to the specific requirements above (single address versus multiple addresses, single contact versus multiple contacts per address) can dictate the entire nature of the code. The UI layer, business layer as well as the data layer all depend on this simple decision.

In effect, the question is about whether the Contact—Address relationship is a 1 to 1 relationship (the simplest scenario) versus a 1 to many versus a many to many (the most complex scenario).

At the database level, intuitively, we understand that this is a big deal. It should come as no surprise then, that the domain (business entity) layer, which is an OO representation of the database schema, will be hugely impacted by this decision.  The UI layer, of course, is the most damned by this decision since it not only has a dependency on the business objects layer but also has to worry about different types of controls to accommodate ‘multiple relationships’ as opposed to single 1-1 relationships.

Extrapolate that single contact form to multiple forms, tied to a large business layer tied to a data access layer tied to an entity layer which finally ties to the database, the change is no longer simple. It could (and usually does) mean days and days of rework and code changes.

The real question should be:  ‘Why do we not have these important requirements upfront?’  Is ‘Agile’ being used as an excuse for ‘we’ll worry about it later?’

Consequences of misinterpreting Agile Tenet 1

1. This common misinterpretation of ‘Start with whatever you have right now’ typically leads to inflexible software design which is not well suited for changes down the road.
2. This simple misinterpretation can add weeks (and thousands of dollars) to any development budget. It typically involves an entire revamp of one or more layers of the application every single time the customer changes her mind. Instead of being an Agile sprint, the process has turned into an expensive, flat-footed marathon. 

Misinterpreted (flat-footed version of) Agile Tenet 2 – Comprehensive Unit Testing

“Oh yes – we do agile – but we just don’t have unit tests in there yet. We make it optional for developers and some of them haven’t gotten around to the unit tests. “

This is the exact anti-thesis of agile development!  Holding daily scrums, doing pair programming and all of the rest can not make your software agile. Only unit tests can!  When major feature changes are proposed, a non-unit testable codebase will need to be inspected for every conceivable breaking point manually.  This is as nightmarish as software development can become. The larger the project, the scarier the nightmare.

Just having unit tests in place can avoid all these issues. 

“The ‘Agility’ in Agile comes from automated unit tests”.

Unit tests are what identify breaking points for you whenever you decide to change some code to accommodate feature changes.  Unit tests are what let you handle a real curve ball requirement that could potentially wreak havoc on your codebase. Unit tests do not do this alone – but if combined with the following, they will greatly reduce chances of bugs making it beyond the developer’s box (i.e. bugs will be caught during development as opposed to QA or worse (the dreaded ‘Production Issue’).  What distinguishes well-designed software from poorly designed software:

1. A well designed object model
2. A normalized, relational database model.
3. A flexible business layer that allows for easy modification of underlying object types (using patterns such as Abstract Factory and Interface based design) and
4. A comprehensive set of unit tests.

The last item (comprehensive unit tests) are also what distinguishes Agile software from ‘flat-footed’ software. If you were to leave out the first three and only have the last item (comprehensive test coverage), you would still have agile software. You may argue that what is the value of having ‘agile’ software that is not ‘well-designed’.

This leads us to the second redeeming quality of unit tests – they force you to refactor your code – so it becomes better designed.

Unit tests, by their very nature, force you to look at your code with a fine tooth comb. For example, if you approach writing a unit test for a ‘GetCustomerInfo’ method, you may realize that the method is trying to do too many thing (connect to a data source, fetch the data, assign the data to a business object etc.). Instead of doing all of that, you reason that it would be better to break that method into a few smaller methods – each of which does one specific thing. Already, you have refactored your code and made it better before you even wrote your first test!

Repeating this process leads to highly refactored code which can be read and understood easily by a new developer on the team. More importantly, during troubleshooting, it helps to quickly pin-point a problem down to a single, small ‘culprit’ method as opposed to a gigantic block of code.

Summarizing Agile Tenet 2 –Comprehensive Unit Tests

  A comprehensive set of unit tests is the best insurance that code can buy.  Agile teams start writing tests alongside code. Some managers argue that they have a team of testers ready to catch all bugs prior to launching the application into production. To them, my response would be:

An agile system catches various ‘breaking points’ for you. In lieu of unit tests, some of these ‘’breaking points’ may even make it to the production system, since it is often impossible for QA teams working under already stressful timelines to catch all of these.

Consequences of misinterpreting Agile Tenet 2

Makes your code incapable of accommodating changes – making it a huge liability rather than an asset.

Summary

• Agile is here to stay. The real question is  –  “How is your team interpreting ‘Agile’?”.  The ultimate test of whether you have implemented Agile correctly is how long it takes you to make changes that are potentially ‘breaking changes?’.
• If you are going to do Agile, do it right. Simply holding daily scrums, doing pair programming etc. does not make a project agile. Making sure your code can easily and quickly handle the toughest requirement change thrown at it, is what distinguishes Agile software from flat-footed code.

Answer to the riddle posted as a teaser to this blog post – “What is voiceless, yet cries and toothless, yet bites..” – The Wind.

The post Agile versus “Flat-Footed” development appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.