Forem: Igor Barsi

Just-in-Time Knowledge: Learn What You Need, When You Need It

Igor Barsi — Sun, 26 Aug 2018 16:27:21 +0000

As makers, we’re always looking for creative new ways to keep our minds sharp and skills relevant. We live in an age where a vast sea of information is available at our fingertips. In this knowledge economy, information is king. When you take a step back to consider the possibilities this creates for personal and societal growth, it’s really quite inspiring.

But what are the ramifications of such boundless access to information?

The JavaScript community has been in a state of fatigue for some time due to constant changes in tooling, libraries and abstractions that seem to be popping up quicker than we’re able to absorb. While the growth and influence JavaScript has had on the development community is something to admire, it came at a cost. An onslaught of blog posts, books, video tutorials, online courses and boot camps, all claiming to teach you the latest and greatest in your field of choice.

Information overload is real and its negative effects will creep up on you.

As you begin your hunt for knowledge, you’re faced with some challenging questions:

Am I finding all the information I need?
Is the information I found reliable?
Am I looking for the right things?

Instead of stretching your mind beyond its limits by consuming 100% of the information you come across in case you might need it, why not learn as you need it?

Just-in-Case vs Just-in-Time Learning

“Experience is a hard teacher because she gives you the test first, the lesson afterward” — Vernon Law

Most of us are accustomed to the format of education provided by traditional schooling. Teachers instruct classrooms of students using standardized material at a fixed rate. Changes to this material are infrequent, and students are often grouped without taking different styles of learning into consideration. You’re periodically tested on the materials that you’ve been taught.

This is just-in-case learning, and it’s the opposite of what you experience in life outside of school. You either acquire raw knowledge without knowing how it may (or may not) be applied at a later time, or you face challenges before you learn what you need. Life is full of twists and turns. You never know what you’ll face next.

If the information you’re learning is not immediately valuable or applied regularly, you end up forgetting the bulk of it. You’ll maintain some level of familiarity over time, but any detailed expertise will be lost.

This method of learning is comparable to the way we regularly consume daily tech news, deep-dive blog posts and lengthy Twitter rants. While the information may be valuable, internalizing it now before you’re presented the opportunity to make use of it is wasteful. At some point, you begin to experience diminishing returns on your investment of time and cognition.

I’d like to explore an alternative approach to learning by drawing analogies with a software program that embodies similar core principles — the JIT compiler.

Compilers translate the code you write to something a machine can understand. Traditional compilers work ahead of time to create an optimized translation of what we write. Modern JIT compilers, on the other hand, translate individual parts of your code as they become warm (ie. as they are used).

These segments of code are translated into stubs, which are then further optimized and re-translated in a more performant manner as their usage increases. If your code’s execution changes and the compiler notices something is amiss, it throws out the stub and starts again. In this manner, the compiler is self-correcting and only commits to working on a translation if the value returned is deemed positive (ie. usage vs effort to optimize).

At its core, just-in-time learning can be explained using the principles that are baked into JIT compilers.

Effectiveness > Efficiency

Traditional compilers are very efficient. They take their time, reading over the entirety of your code before translating in the most efficient way possible. You can become very efficient at reading and processing information this way by committing vast amounts of your time to consume as much knowledge as possible.

This isn’t the best way to learn.

Instead of focusing on efficiency, stop and ask yourself if you’re learning the right thing?

Too often, we focus our time on “getting things done” instead of “getting the right things done”.

Whether it’s personal or team productivity, take your time and make sure you’re heading in the right direction. Only apply effort when it maximizes value.

Delivery teams put a high emphasis on reaching peak velocity. Understand that velocity is the combination of speed and direction.

Correct Yourself

While translating, JIT compilers will immediately throw away existing optimizations if newly interpreted logic disproves previous assumptions.

As you learn “on the fly”, you will come across information that falsifies your previous knowledge. Heed these discoveries, as they could be an indication of questionable sources. Don’t let confirmation bias take hold and consider where you’re getting your information.

When you’re learning something new for work, you’ll likely be pressed for time. With a deadline looming, you’ll be tempted to rush your learning to get the job done.

Once again, direction matters. Validate against your network, filter out dogmatic opinions and do your best to ensure your information is credible.

Organize Information

As a JIT compiler parses your code, it segments logic and creates stubs that are indexed by line number and variable type. This indexing makes sorting, filtering and searching for relevant parts of your code a breeze during optimizations.

As you go about your day, communicating with co-workers, skimming newsletters and scrolling through your news feeds, you’ll come across some potentially interesting and useful information.

If you were to sit down, collect all that information and fully digest it on a daily basis, you’d be swamped. There is only so much time in a day. That being said, you wouldn’t want to discard what you found, potentially missing out on some key learnings.

Find a service, like Pocket or Instapaper, that lets you collect useful links for later. Like a compiler’s stubs, you’ll want your service to support search, categorization, tagging, sorting and filtering for easy access. Determine what groupings work best for your learning style and ensure they’re readily available when you need it.

Determining the value of an article often doesn’t require its full consumption. Most bloggers include the gist of what they’ve written in their conclusions. Skimming that will often give you enough context to decide whether or not the post should be saved for later.

There’s a Caveat

“The more basic knowledge you have … the less new knowledge you have to get.” — Charlie Munger

While the benefits are enticing, just-in-time learning does not replace knowing the basics.

Schools teach you fundamentals for good reason. They’re the building blocks used to develop a deeper, more specialized understanding of the subject matter at hand. Without that foundation, you’ll have a hard time ramping up on new material. Starting from something is easier than starting from scratch.

In addition to knowing the basics, you should also know the landscape.

Broad knowledge and surface-level understanding of the many edges and specialties of your field will help optimize your just-in-time learning. Otherwise, how will you know what to learn when you’re faced with an unfamiliar problem? You need to be aware of your options before you can decide where to invest your learning.

The more you know, the better primed you will be to tackle new challenges. Continuous learning is the key to personal development and success. Growing smarter every day will compound and propel you ahead.

What To Do When You Don’t Know

“Education is knowing what to do when you don’t know.” — Michael Lewis, The Undoing Project

At the end of the day, a good mix is key. Invest time in learning the fundamentals of your craft, while building a framework of resources and techniques to prepare you for when you don’t know.

Remember the core principles of just-in-time-learning:

Focus on effectiveness by regularly asking yourself whether you’re learning the right thing?
Correct yourself when you come across conflicting data. Validate your sources and avoid dogmatic opinions.
Organize your information in such a way that is painless to access just as you need it.

Don’t invest the time and effort into learning something in case you’ll need it. Learn when you need it.

Thanks for taking the time to read this post!

Please ❤️ and follow if you liked what you read and subscribe to stay in the loop 😁

Originally published at www.igorbarsi.com.

Groom User Stories Your Delivery Team Won’t Hate

Igor Barsi — Thu, 31 May 2018 01:01:00 +0000

When you think of a good user story, you might imagine clear, succinct definitions of features that address real user needs and provide solid business value. They are the PO’s breakdown and representation of where the business needs to grow to keep customers happy and ensure future success.

While this is very meaningful from a business perspective, I find that writing user stories in this way ensures that they are only meaningful to the business. The focus, terminology and scope is directed at a single audience — those that wrote the stories in the first place.

This often causes issues for members of the delivery team that don’t share that same mental model. Implementation details and blockers are not clear. Developers are fumbling over conflicting technical requirements and duplicated work. QA is never certain that the story is entirely finished, unsure that listed acceptance criteria cover all expected test cases. Ultimately, these issues make it impossible for the PO to accurately track progress.

This is the kind of wasted velocity we want to avoid.

In order to overcome these issues and groom effective stories, changes will need to be made to the team’s grooming process. User stories should bring value to the entire team, unifying and guiding all those involved through the delivery process.

In the following sections, I’ll shed light on some of the more glaring issues I’ve experienced and offer a few suggestions on how to make grooming less painful.

Write User Stories That People Will Actually Read

We live in a world of short attention spans and limited focused mental bandwidth. Wether you believe the click-bait posts perpetuated by news giants or prefer to remain skeptical of the findings, the impact modern technology has had on the way we consume (and ignore) information is undeniable.

When discussing leadership, speaking, writing and really any activity that requires the attention of others, you’re often advised to grasp that attention as quickly as possible and hold onto it as long as you can. As a result, the content we create is formatted and organized in a way that caters to the impulsive needs of our target audiences.

Why don’t we apply these same principles to writing user stories?

When it comes down to it, our teams are full of regular people. We’re all busy, with mounting emails, endless meetings and constant Slack notifications. If our stories aren’t written in a consumable way, they simply won’t be consumed at all.

When you sit down to write your next user story, keep the following characteristics in mind.

Clear acceptance criteria that outlines expectations and user needs. These should be comprehensible, succinct points that are narrow and focused on individual requirements. This will ensure developers and QA can digest, implement and test every aspect of the story. In theory, someone should be able to walk off the street into your office, read a user story and get a descent sense of what is being asked.
Vertically sliced segments of functionality that cut through all architectural layers of the application. Stories should add complete, functioning value to the product. To achieve this, a user story must capture all work required to be completed through the data, business and presentational layers of the application. Technical sub tasks can be broken out to tackle each layer separately, if sensible, but the story itself should capture the final state of a functioning feature.
Focused on a single workflow or unit of value as part of a greater initiative. A user story shouldn’t cover too much ground, but just enough to deliver value. Bloated stories will come off as daunting and lead to avoidance, while slim stories will seem tedious and pointless, influencing the team to rush implementation and “move on to the next thing”. Striking that balance is key to maintain engagement while still delivering something meaningful.
Prioritized ruthlessly. User stories should be constantly re-prioritized and re-ordered in a way that represents current needs, adjusting for ROI, effort required and blocking dependencies accordingly.

Remember, we’re all regular people at the end of the day. Through the myriad of distractions and depletion of focus we endure, let’s put some effort into making our delivery process as painless as possible.

Don’t rely on willpower alone to prevail. Reduce the friction and get your team focused in a unified direction.

Include The Whole Team

Traditionally, stories are written by someone with a mental model of where the product needs to grow. They proceed to formalize these thoughts and break them up in a way that makes sense to them and the business. Finally, the result of this exercise is shared with the rest of the team for implementation.

The entire delivery team is responsible for shipping value to your customers. Every member of the team will have difference needs and styles of work that have to be taken into consideration. To be truly agile, every member of the team needs to function as an inter-disciplinary cohesion of diverse talents. As such, members of these diverse roles should not be expected to bend to the style of writing, organization and planning that’s optimized for the business. The chance of this shared context translating well across roles are slim.

While grooming, take your team’s dynamics into consideration. Include every role in the process.

Through shared understanding, you reduce the risk of miscommunication and divergence during delivery. Every role on your delivery team has different skills and needs. By defining work in a diverse way that speaks to all talents, you can unlock your team’s full potential and reach peak velocity.

Separate Concerns Between Task Categories

Project management software, like JIRA or Asana, provide you with the tools you need to successfully guide and track your software project from start to finish. These tools are considered standard practice for modern software initiatives.

The breadth of features provided by these tools equip your team with great flexibility through configuration, but with that comes the potential for complexity. Your team could end up drowning in countless workflows, views and reports, ultimately causing the very issues these tools set out to solve.

Clean coding teaches us separation of concerns between classes and modules through what is called the Single Responsibility Principle. As originally described by Robert C. Martin in Agile Software Development, Principles, Patterns, and Practices, a class should only have one reason to change. This segmentation ensures that a collection of logic is encapsulated and focused on a single purpose.

This same philosophy should be applied to the tasks we create in our project management software. Too often, information is duplicated across epics, stories, sub-tasks, defects, etc. This confuses anyone who tries to pick up the pieces through the delivery process. Developers are scrambling between tickets to ensure they capture all requirements, often bothering the PO if clarity isn’t achieved. QA doesn’t know where to look to find the “true” acceptance criteria that needs to be tested. POs have to remember to update every ticket affected by a change in requirements, falling prey to human error.

These tools and processes are in place to help us achieve velocity. If instead they’re crippling our progress, something is broken.

From my experience, I’ve had good results sticking to the following classifications and separations of concerns between ticket categories.

Epics should be written by the PO to capture entire initiatives. These are high level tasks that are written in an executive level language that speaks to business owners. Epics should state clear goals that the team can rally behind and stay focused.
Stories should be written by the PO, breaking epics down into sizeable chunks of functionality. I already went into user story writing in the previous section, but I want to re-iterate how critical it is that stories stay relevant to the business. This is the PO’s value-centric breakdown of a larger initiative that can be used to track the overall progress of the delivery of said initiative.
Sub-Tasks should be written by developers to outline the technical implementation details for a given story. These tasks are for developers only to be completed during the sprint. A single story could have one matching task, many tasks or share tasks between other stories. The goal is to create tasks that logically break down the work required of developers, across stories, to be utilized in a way that’s most efficient for them to deliver. Once all tasks linked to a story are completed, it should be ready for test.
Defects should be written by QA to capture errors or missed criteria in stories. Defects should be described in detail, with clear steps to reproduce and screenshots or videos If possible. Stories should be linked so that missed acceptance criteria is clear.

The distinctions defined above should be clear and their language consistent. Product should be able to define what they need in a language they understand. Development and QA should be no different. With this clean separation, each member of the team can work as efficiently and comfortably as possible.

Groom User Stories Your Delivery Team Will Love

These days, high quality software doesn’t get delivered by a single person. There are groups of talented and diverse individuals in different fields of practice with varying disciplines and perspectives. To truly get the most out of your delivery team, the stories that ultimately drive the product’s development should be groomed in a way that compliments these dynamics.

Readability is critical in ensuring that your stories get consumed efficiently, with minimal errors and confusion. Remember, anyone should be able to walk off the street, read a story and grasp the ask.
Inclusion among varying disciplines in the team before and during grooming could proactively prevent lost time and churn during implementation.
Separation of concerns between task categories improves clarity as to where information can be found and reduces duplication across tasks.

Grooming doesn’t have to be painful.

We take pride in the work that we do and strive to ship successful products. There should be a willingness in us all to pivot and adjust process to reach that shared goal. Well crafted user stories should unify the team’s joint vision and ultimately drive the product to success.

Groom user stories that empower your team and they will deliver.

Thanks for taking the time to read this post!

Please ❤️ and follow if you liked what you read and join my newsletter to stay in the loop 😁

Originally published at www.igorbarsi.com.

Habitual Testing: Transform Negative Software Testing Culture By Leveraging Your Subconscious

Igor Barsi — Sun, 01 Apr 2018 16:32:58 +0000

I think we can all agree that testing code is valuable.

Well tested code assures the completion of acceptance criteria, guiding implementation by outlined requirements. It empowers you to extend and refactor with a sense of safety, knowing that existing functionality won’t break as a result of your changes. Over time, your team gains increasing returns as the growing number of tests reduce the likelihood of surprising, hard-to-diagnose bugs appearing and derailing production software, often coming at a cost of significantly more time than it took to write the tests in the first place. Not to mention, this increased quality lowers the chance of production bugs being exposed to your customers, potentially driving them away from your product as a result. These tests even act as a form of living documentation for your code, clearly describing intent…

The list goes on.

Ultimately, testing leads to increased software quality, reliability and customer retention, while at the same time reducing overall cost. Most developers are well aware of these benefits. Yet, many of the production software we write is severely under-tested.

Why do we seem to resist following a practice that is ultimately designed for the collective benefit of all stakeholders?

I believe it comes down to culture. A shared mindset across organizations to turn a blind eye to the undisputed value that well tested software brings. Perhaps it was pressure from management, instilled in the company from early contributors or developed slowly over time due to overall lack of diligence. No matter what the cause(s) may be, it’s ingrained in your company’s culture now and you’re stuck. This quote from Tom DeMarco and Tim Lister’s Peopleware captures the issue perfectly:

“People hate change… and that’s because people hate change… I want to be sure that you get my point. People really hate change. They really, really do.”

– Steve McMenamin, The Atlantic Systems Guild, 1996

People don’t like being pushed out of their comfort zones. Even if a change is clearly positive, it is in our nature to resist any irregularity that challenges our norm. It’s easy to sit back and coast along, but if you want to reap the benefits outlined above for your team, organization and ultimately the customer, change will have to be faced.

Breaking culture is hard, but it’s not impossible.

In the rest of this post, I’m going to dive into what I call habitual testing. A collection of techniques and patterns I’ve adopted across the organizations I’ve worked at that have helped slowly build testing awareness and intuition. This process aims to instil small bits of change over time, while gradually forming good testing practices as the team adjusts and observes the benefits.

Think Before You Test

I came across this tweet a while back from Guillermo Rauch‏ that really spoke to me:

In only a few words, he was able to sum up much of my own philosophy of how to approach testing. Especially in teams that don’t support testing as a core part of their development process.

We only have so much time to test, so test smart.

Some teams get turned off of testing large legacy projects due to the sheer amount of code that needs to be covered. Others might question the value of spending time writing thousands of lines of detailed test code to cover disproportionately less lines of production code.

I’m not advocating that you drop what you’re doing to test every line of code in your project. The point being conveyed here is that you should write tests that are valuable. 100% code coverage does not necessarily mean that your code is well tested. Not all code paths need to be unit tested with precision. Not all APIs need integration tests. Not every UI component/workflow needs end-to-end tests. It’s our responsibility as engineers to determine what tests will bring us the most return on the time invested in writing and maintaining them.

An often shared model illustrating different forms of testing is what’s known as the Test Pyramid :

This diagram is often used to emphasize the importance of having a wide base of small, fast unit tests that cover the whole codebase, with some integration tests to “fill the gaps” and a few E2E tests to tie everything together. Alternatively, if we were to break down the diagram by customer value (in terms of certainty in the product’s complete functionality) and cost (effort expended to write), we would get the following:

Unit = low value, low cost
Integration = medium value, medium cost
E2E = high value, high cost

The more surface area a test covers, the more expensive (ie. time consuming) it is to implement, but the most value that it brings. Larger tests are less precise but more accurate at validating correctness by user story acceptance criteria. To put it another way, your tiny units of work can function absolutely perfectly but provide no certainty that the API your customers hit will respond in a way that is acceptable.

If we were to re-draw this diagram in a way that better represents this new mental model, we might get something like the following (as shared by Kent C. Dodds):

Here’s how this new diagram can be interpreted:

Write mostly integration tests to ensure the program is running correctly. Testing your units interacting with one another allows you to create scenarios that match real customer use cases. Does your payment API react as expected when an expired credit card is provided? Does your authentication layer correctly handle password resets? These could all be potential customer requirements that you’re able to validate directly, providing highly valuable assurances to your customers. Make sure you test optimal cases to confirm functionality and plenty of fail cases to ensure errors are being handled correctly.
Write unit tests for complex components with high variability and many split code paths. These are typically the oldest, most convoluted parts of your application. Unit testing these heavily will help alleviate the fear of “breaking things” when you are forced to modify them. Unit tests should be short and concise, acting as a form of detailed usage documentation.
Write E2E tests for critical workflows that don’t change frequently. The latter is critical, as these are often very time consuming and brittle tests to write. Any time your UI or API’s interface needs to be changed, these tests need to be updated. While they provide high value, as they test exact workflows, use them sparingly and only when most beneficial.

Apply these insights to your testing strategy to ensure you get the most return on your investment. Remember to take a step back before writing a test, reference the points above and ask yourself if your current approach is appropriate.

Be a Good Boy Scout

Another deterring aspects of fully testing a completely untested codebase is the potential need for heavy refactoring to support sane testability. Most code written without testing in mind is often untestable as a result (ie. giant functions, several dependencies, global state, etc). The older and larger the codebase is, the more daunting this task becomes. Combine this with an ever growing backlog of new feature work and looming deadlines and you’re left with a recipe for disaster.

I don’t blame you.

Tackling a large, untested codebase head first, much like jumping into an aggressive diet or workout routine, is simply too much to take on at once. The goal of having a fully tested codebase doesn’t seem feasible. What you want to do is to foster a habit of piecemeal testing, attacking the monolith one step at a time.

In her book Succeed, Heidi Grant Halvorson lays out a simple practice to overcome procrastination that she calls an if-then plan, in which we identify a scenario that we would like to respond to by completing a certain task.

“Planning creates a link between the situation or cue (the if) and the behaviour that you should follow (the then).”

When the cue is encountered, the desired behaviour is triggered automatically. This is the key to the success of this plan, the sub-conscious response that we teach ourselves won’t tax our self-control and ensuring that the desired task gets completed.

By adhering to a few simple guidelines, you can teach yourself (and your team) the required if-then plans to leave every nook and cranny of your codebase with better coverage than when you first touched it, as if it were second nature.

Test every new bug — When a production bug is reported, your instinct is to immediately sift through logs and attempt to replicate the error locally before proceeding to tinker and develop a solution. Before committing that code, stop and write a test. Not only does this increase code coverage, but it guarantees that if this bug is ever re-introduced it will be caught by your test runner, not your customers. If there’s no test, it didn’t happen.
Test every new feature — New code is easy to test. You have full control over how to encapsulate your logic, split and limit dependencies and ultimately make the feature as painless to test as possible. Challenge yourself to sensibly test any new code that you write until you’ve achieved a comfortable level of certainty in what you’re about to ship.
Test before you refactor — Refactoring runs the risk of introducing regressions by incorrectly re-implementing old code based on misinterpreted intentions. Before you refactor, write some tests to define how the code is functioning correctly today. This way, you can assert and rest assured that your refactored code is functioning exactly as intended.

Integrating these if-then plans into your development process introduces light testing sprinkled throughout your day-to-day tasks. Before you know it, you’ll be thinking about ways to test your code before you write it.

Make it Simple

Charles Duhigg compares our willpower to a muscle in his book The Power of Habit, suggesting that there is only so much willpower we can exert before we run out of steam. Over-exerting ourselves early during trivial tasks results in depleted self-control and lack of discipline when the time comes to apply ourselves for the work that really matters.

Our work lives are full of tasks that require willpower. Checking emails, keeping JIRA tickets up to date and responding to Slack notifications gradually deplete your willpower reserves throughout the day. Eventually, you can become so drained that you start to slip and lack diligence when it comes time to work on more meaningful tasks (like testing your code).

While you can take measures to reduce the negative impact and frequency of these menial tasks, the reality for most of us is that we’re not in a position to block them out entirely. What we are in a position to do is make sure that testing doesn’t get negatively affected by our drained reserves. By making testing as straightforward and painless as possible, we reduce the effort required to write them and in turn minimize the risk of writing rushed, careless tests when we hit our lowest point of determination.

Write utility functions to reduce duplication of commonly repeated tasks. This is common practice in feature, DRYing out repetition and code duplication. Make sure the same philosophy is applied to test code. Do you find yourself creating a new user, generating a login token and applying to to requests for all API integration tests? Are you always stubbing out Stripe APIs when you test anything payment related? Write a utility that takes care of that for you in one line. The more you extract, centralize and simplify the prep work, the more streamlined and approachable testing becomes.
Leverage code snippets/generators to bootstrap new tests quickly. As you write more and more tests you’ll establish certain patterns. Your tests will start looking the same. At this stage, taking some time to separate unique test code from the scaffolding will enable the use of code generators. These snippets can be mapped to key combinations in most modern editors and inserted at will, removing the need to hand write (or likely copy/paste) the same code from previous tests over and over again. This is the lowest form of yak shaving that really sucks the enjoyment out of writing software. These templates can act as boilerplates for new tests, removing the busy work and make writing tests feel like less of a chore.
Create fixtures for your data models that can be used to seed fresh test databases. There’s nothing more frustrating than having to mock and “stage” the right data for your tests, especially if an integration test touches several entities with their own dependencies. Detailed, randomized test fixtures with robust extensibility make data generation a breeze. They even provide the added benefit of painless seeding for local environments and one-off staging servers for demos.
Make debugging easy for everyone. No one likes debugging with print statements. While it’s standard these days to work in an engaging debugging environment for application development, don’t leave your test build hanging. Make sure the effort required to debug and step through test runs is minimal, preferably just as intuitive and supportive as your main application. The last thing you want is to have everyone on the team start skipping broken tests or re-running intermittently failing tests because the effort required to find and fix the root cause is too great.

With the right tools at your team’s disposal, testing can become less of a chore and at times even enjoyable. We go to great lengths to make our development environment as pleasant to work with as possible. It’s time to apply the same mindset to our test tooling.

Have Rules

Sandi Metz gave a talk called Rules, which outlines 5 rules for writing object oriented code. Furthermore, she digs into how social scientists define rules and the impact they have on willingness and self-discipline. The results are illuminating, and the benefits can be applied across domains.

Ultimately, the rules you set are arbitrary and it’s perfectly okay to break them if reasonable. It’s the very existence of these rules that bias towards co-operation and collaboration, towards maintaining the “state of things”. By setting hard rules that govern how testing should be done, you are effectively influencing followers to uphold standards and push non-followers towards adhering to your norms.

When you start thinking about the kinds of rules you want to set for your own team, keep the following two metrics in mind:

Code Coverage — Add code coverage analysis to your test suite and set some rules dictating how much coverage you intend to maintain. Integrate tooling into your version control provider of choice and automatically block pull requests that don’t meet your standards. Perhaps there are certain limits you want to set per metric or maybe you just want to ensure overall coverage doesn’t decrease. Once again, the rule itself isn’t entirely important. Code coverage metrics are not a silver bullet, but adding limitations will be a constant reminder to the team that testing is a key indicator of quality.
Test Coverage — Writing tests is a good thing, but writing the right tests is where you get the biggest gains. Just because your code is covered doesn’t mean it is tested sufficiently. New or modified tests should be compared against requirements to ensure all identified use cases have been covered. While this manual process can be tedious at times, these spot-checks instil an understanding of the importance of asserting all required use cases. You may begin to notice that these spot-checks become mute, that use cases are always being covered and these manual checks are only slowing you down. That’s when you know the rules have done their job.

Rules can have a profound effect on your team, wether they realize it or not. The metrics detailed above may not be perfect, but they serve the purpose of nudging team members toward the norm of constant, habitual testing.

Develop Habits That Work For You

Embracing effective software testing patterns can be a daunting, uncomfortable and downright painful experience. It doesn’t have to be. Take advantage of the mechanics hardwired in your brain. Create a framework that fosters the formation of habits that encourage a strong testing culture.

Think before you write your tests. Make sure you’re getting the maximum return on your investment.
If-Then plans trigger an automatic response to certain coding scenarios. Take advantage of them to elicit a positive response (via tests).
Tooling that supports painless testing will ease the barrier of entry for writing future tests.
Rules will have an impact on the willingness and self-discipline of your team when it comes to diligently testing their code.

The final takeaway to making habitual testing a success is believing that it’s possible. Forming habits can be a challenge. It takes significant time and effort to realize the fruits of your labour, but the result is truly satisfying. To quote Charles Duhigg once again in The Power of Habit:

If you believe you can change — if you make it a habit — the change becomes real.

Develop positive testing habits that work for you. Don’t trust willpower alone to prevail. Leave conscious choice and debate out of the equation.

Make it automatic.

Thanks for taking the time to read this post!

Please ❤️ and follow if you liked what you read and join my newsletter to stay in the loop 😁

Originally published at www.igorbarsi.com.

Sprinting Our Way To Missed Deadlines

Igor Barsi — Sat, 13 Jan 2018 21:17:16 +0000

Photo by Andrew Neel on Unsplash

When I was first exposed to Scrum, I fell in love.

The process was straight forward. The team agrees on a prioritized list of tasks to complete in a consistent block of time. A sprint. You meet daily to touch base, ensuring everything is on track. By the time the sprint is complete, some product functionality has been shipped. The client is happy. Finally, you regroup for a retrospective, discussing what went well and what went poorly. Then you start all over again. It just made sense.

I’ve been fortunate enough to come across some great opportunities throughout my career, exposing myself to diverse development environments and teams across disparate industries. I’ve built in-house line of business applications, campaign/content sites for a variety of clients and currently (at the time of writing) the core platform at a mid-sized startup. Though my experiences in these roles have had many differences, one sobering fact seems to hold true across teams and organizations:

Deadlines are missed. Often.

Yes, estimation is hard. Yes, software project planning is hard. But why, as an industry, do we seem unable to achieve any level of certainty in our project plans? Agile methodologies have brought us leagues ahead of “waterfall” development, and we have a plethora of industry-vetted estimation techniques (ie. poker points, t-shirt sizing, relative mass, etc) at our disposal, yet dependable roadmaps continue to elude us. I can’t seem to shake the feeling that this should be working. What have we been doing wrong? What am I missing here?

After much reflection (and frustration), I’ve come to a realization.

Time-Boxed Sprints are Problematic

During one of my team’s feature planning sessions, a colleague expressed his dislike of Scrum. He called it “artificial hustle”. His reasoning, and I’m paraphrasing here (my memory is not as sharp as some), was that it's needless “process” inhibiting our work. We have a prioritized backlog. We know how to group and tackle the tasks best. We know that our estimates will inevitably change and tasks will evolve as we work. Why time-box us into uniform segments of work? We can keep daily stand-ups, but run our own retros after a milestone has been reached (ie. a critical feature has been shipped), not after some arbitrary amount of time has passed. It feels forced.

I have to say, I didn’t agree with this sentiment at first, but the focus on value got me thinking…

Looking back at our recent sprints (and most sprints I’ve been a part of, really), I can’t help but feel as though there was never enough time to ship real value in the course of a single sprint. By value, I don’t mean stable code or singular components. I mean business value (ie. user stories), a working piece of end-to-end product that can immediately be operationalized and put to use.

I figured this was a problem with the way our tasks were defined, and perhaps there is some blame to be placed there. However, some stories are simply too large to reasonably break down any further, lest you sacrifice that end-to-end completeness. Even so, a story that is estimated to be around 3 days worth of effort can still be missed in a weekly sprint, and (at least from my experience) often is. Something’s got to give.

I forced myself to take a step back and remove my rose-coloured Scrum glasses to objectively scrutinize this process, attempting to pinpoint potential reasons for our lack of efficiency.

Here’s what I came up with.

Too Much Churn

I narrowed down what I believe to be Scrum’s biggest “time-sinks” to the following, un-ordered list. Keep in mind, this is all from personal experience. While I’m sure the processes followed by my previous organizations weren’t perfect (what process truly is?), I feel that these issues are not unique to me and that many of you have had similar gripes with your team’s software planning process.

Tasks are too vague — Insufficient information is provided in the ticket to guide the implementer down the right path. This is not uncommon, as most clients don’t really know what they want during the first pass of product development. Often times, they need something tangible to have that “ah ha“ moment. However, time-boxing these tasks could lead to squabble and back-and-forth on implementation details that ultimately loses far more time than it would have taken to iron out these details in the first place.
Tasks aren’t familiar — When a task involves unfamiliar tech, new or undocumented APIs or if the domain is inherently complex, original estimates might not hold true throughout the sprint. Letting these tasks slide until your scheduled retrospective before re-estimating and planning could cause needless “trashing” and future rework.
Task dependencies within the sprint — Team members become immediately blocked when tasks have dependencies or require further input. There is an illusion that all tasks are “up for grabs” at any time. In reality, what you end up with is contributors tripping over each other trying to glue coupled tasks together between their branches.
Tasks aren’t related — The sprint is full of disparate tasks that require constant context switching. Some teams insist on planning sprint tasks by type (ie. feature, bug, enhancement, tech debt, etc), only allocating a certain percentage of each task type per sprint. This seemingly “even” distribution of work might sound nice to the client/board, but its a constant cognitive juggle for the team. This fragmentation causes a compounding loss of efficiency that is often untracked and poorly reflects on the team’s ability to deliver.
Research tasks create additional work — Investigation, if fruitful, leads to the creation of implementation tasks. Deferring said implementation work till a later sprint to avoid “scope creep” costs the team that immediate knowledge they’ve built up during their investigation, only to be ramped up again when approaching the problem a second time.
Research tasks continue forever — When investigative work is not contained in some way, it becomes very easy for the assignee to get stuck down a rabbit hole. Parkinson’s law might drag them on until the sprint retrospective.
Implementing another person’s estimate — Regardless of your estimation method of choice, there will always be some discrepancy between contributors. The larger the gap, the further your sprint commitment is from reality.
Unable to truly maximize effectiveness — When you know you only have a limited time to complete your work, you’ll always shy away from grabbing large tasks near the end of the sprint. This holds especially true if the remaining larger tasks are unfamiliar. What you end up with is most team members grabbing one or two larger tasks, followed by a few small ones near the end, leaving the rest.

The Cost of Time-Boxed Sprints

While these issues clearly cause a loss of time and efficiency, there are other potentially more damaging costs that are not immediately apparent.

Planning — When contributors are forced to “guesstimate” complex issues in unknown domains for the sake of plugging numbers into a spreadsheet, no real value or certainty is provided to anyone. Not the board, the clients, the Product Manager and definitely not the development team.
Quality — When the team is scrambling to get tasks done before their “time is up”, especially if there is a minimum quota enforced, quality is inevitably sacrificed. Focus is placed on shipping tasks, not valuable working software.
Credibility — Continually missing release dates and shipping faulty software will degrade your credibility with your clients and ultimately your team.
Burnout — The stress from rushed work and constant jumping between contexts is unnecessary load that taxes your team’s psychological wellbeing.
Morale — At some point the consistent lack of quality, missed deadlines and never-ending burnout will ultimately crush the team’s morale.

Looking at the list above, you should be wondering… Aren’t efficiency, quality and timely delivery the very qualities that Scrum (and more generally Agile, for that matter) claims to facilitate? Is this really the best we can do?

I think we can do better.

Value-Based Sprints

In my search to improve my team’s process, I read through Ken Schwaber and Mike Beedle’s Agile Software Development with Scrum. The book conveys an understanding of why thinking of software development as “new product” development is necessary, filled with detailed descriptions of the Scrum process backed by plenty of real world success stories. While the book is a bit dated (published 2001), we still follow many of its steps today. However, the following 2 characteristics stood out from what I’ve been used to:

Sprints should have a clear goal that the team agrees on.> 2. Sprints should run for a month.

These points may seem small, but they can have a significant impact. First, setting a goal for your sprints immediately shifts the focus from closing tickets to reaching some milestone, to achieving value. Second, extending sprint time to a month gives your team a lot more breathing room to see entire features through till the end. While I’m not advocating we all extend our sprints (time-boxing in a bigger box doesn’t solve the real issue), you wouldn’t feel encouraged to “shrink” your stories when time isn’t such a constraint.

The point I’m trying to make is that our focus should be on delivering valuable, working software to our customers and our processes should encourage and facilitate the attainment of that goal.

I propose we make the following additions/modifications to our sprints:

Clear sprint goal — A sprint should have a purpose. Hone in on critical features/stories and identify what should be delivered first. A good starting point might be 3 critical deliverables. Everyone on the team should be briefed and understand and agree on what you’re all trying to accomplish at the start of every sprint. Listen to your team and adjust if needed. The sole focus of the group should be to deliver on that goal as efficiently as possible.
Don’t time-box — As we shift our focus from time to value, we lose the constraint to fit as much work as possible into a set amount of time (see The Spanish Theory of Value). That being said, you should still aim for short cycles. A fast feedback loop is key and should be considered when planning each sprint, without constricting it.
Group related tasks — Fragmentation is a huge productivity killer and so often overlooked. Its understandable, as a product manager, that you want to move your initiatives along while addressing any critical bugs or enhancements that inevitably pop up. The reality is that a sprint full of small tasks that cover a large application footprint kill efficiency. Every time you bounce from task to task you have to wind down and ramp up on the relevant context, dig into a brand new area of code and zone in. It may seem small, but understanding the psychological dynamics of flow will make it clear that it adds up. This doesn’t need to be hard. If you are trying to deliver a feature that affects a view in the application, try to get some high-value bugs in the sprint that touch that same view. If an urgent bug pops up with your login flow, maybe its a good time to tackle some pesky long-lived tech debt to optimize that flow. When your contributors are in a flow state, they can fly through these auxiliary tasks much more efficiently then when they’re scattered.
Size stories, don’t estimate — Attaching time based estimates to stories gives off a false sense of certainty that a task will be completed in that time from the moment it is started. Anyone who has been an engineer or managed them long enough will know this is never the case. Concentration will always be broken to some extent. Use an effort based estimation technique, such as t-shirt sizing or points (if measurements equate to time, you’re cheating), to provide a sense of scale for the deliverable. This is what should be used when planning sprints.
Break stories down in detail — Granularity is your friend. The more vague a task’s description, the greater the possibility for error during implementation. There is a balance though, as you don’t want your contributors to feel like code monkeys. Your tasks should be clear, with enough information and supporting links to documentation to guide contributors down the right path. No more, and definitely no less.
Stop if needed — If blockers (ie. design errors, vague requirements, implementation discrepancies, etc) emerge that cannot be resolved quickly then don’t be afraid to stop the sprint. I find this is harder to do when sprints are time-boxed, likely because the team is focused on reaching that deadline. The reality is, these disagreements and surprises end up costing more if ignored, rushed, resolved ad hoc or overlapped with concurrent implementations that end up getting re-written or tossed. Take time to regroup and align, then continue or plan an altered sprint if necessary.

Conclusion

At the end of the day, this is all speculative. I’ve never worked at an organization that adopted all or even most of these concepts. There might be some Kanban influence in my thinking, although I’m not knowledgeable enough in the practice to say for sure. What I’m trying to create is a way of thinking that moves focus away from “precise” estimates and process for the sake of (ultimately inaccurate) project planning over to efficiency. To quote The Agile Manifesto:

Working software is the primary measure of progress.

Don’t track time, track progress. The question you must continue to ask yourself is:

“Are we delivering value to the best of our abilities?”

If the answer isn’t a confident “Yes”, perhaps its time to approach your process more critically.

Thanks for taking the time to read this post!

Please ❤️ and follow if you liked what you read and join my newsletter to stay in the loop 😁

Originally published at www.igorbarsi.com.