Food, Attention Deficit and Context Switching

“The art of eating your work.”

Okay, had a stray thought while eating breakfast one fine Saturday morning.  It dawn on me that in today’s twitch generation, many people have fallen victim to the dangers of attention deficit and context switching.

Attention deficit (AD) is chronic condition including attention difficulty, hyperactivity, and impulsiveness.  It’s where you have trouble focusing on one thing for a long period of time.

Context switching (CS) is the case where you are interrupted (either externally or internally) with your work and switch to something different.  In the process of switching, Gerald Weinberg proposed in “Quality Software Management: Systems Thinking” that for over 99% of people, it decreases productivity, starting at 20% by adding one more project.

context switching

Both AD and CS go down to even emailing and talking on the phone at the same time or working on a task and then checking LinkedIn or Twitter for a post updated to you.  For me, I’m a victim of wanting to check an email or switching between the remembering of a task and then wanting to switch to that now in order to get it done before I forget it again.  Often, I have to re-remember what I was doing in the first place!

So it dawned on me that I should be approaching work like I approach eating.  I eat one thing at a time.  I focus on eating until done and I cannot stand wasting food.  I won’t stop until I’m done.  Every so often, I’ll run out of time to finish, so I just save the food and then finish it later.

My eating habits are certainly mine and everyone has their own, but consider picking up your best habits and applying them to your work, whether it is for eating, watching the Lord of the Rings / Hobbit marathon or playing basketball.

What I’ve found to help my modern day “ooh shiny” syndrome be held at bay are through the following techniques:

  • “Stop Starting and Start Finishing” – A great slogan from the Limited WIP Society and the idea behind Kanban.  Using Kanban boards, whether personal and / or professional can really help decrease context switching
  • Turn your notifications off! – Phone notifications, email, alarms, alerts, etc.  Create a period of no interruption in advance and close your door, shut yourself out.  This is not possible if you are tech support, but you can at least minimize the noise and clutter of all the devices you programmed to bother you on a daily basis
  • The Pomodoro technique is fabulous way to place structure into your work day.  You get 25 minutes of focused time with an actual timer where you are not allowed to have interruptions.  If you do, you are supposed to write them quickly down and move back to your task.  If the interruption is urgent, then the pomodoro must stop and you have to begin from the start again to continue.  You get a 5 minute break to take care of the shiny objects and then start again, doing a set of four time in which you get a 25 minute break

These methods help combat attention deficit and context switching, but I’ve found that treating my tasks like food has made doing these “a piece of cake”.

Advertisements

Dual Track Scrum Tools and Techniques, Part 2

Within Scrum, a product backlog is used for tracking prioritized development requirements as normally determined by the product owner.  In Dual Track Scrum, it is recommend to use a separate backlog for the Discovery track.  Essentially, the discovery track backlog will “feed” into the product delivery backlog.  Discovery tracks would include techniques such as User Research/Validation, story mapping, building and testing personas, engaging in “what if” scenarios on design, creating minimum ceremony prototypes and tracking Key Performance Indicators.

Consider the opportunity canvas from my last blog (https://agilemichaeldougherty.wordpress.com/2015/08/24/dual-track-scrum-tools-and-techniques/), which covers the pains, remedies, experiments, ideas and options with continuously validating the right solution is being developed.  From that opportunity canvas, user research helps determine what your target audience wants is fully understood.  This can be done via user feedback groups, surveys, usability tests (like A/B Testing) tracking metrics and reaching out directly to the user base.  Now, if you don’t have an existing product, reaching out directly to the user base may be your only option to get direct and candid feedback of product ideas.

Story mapping is a core Agile principle similar to story boarding in the film industry where each step within a solution are created visually through a low fidelity interface in a top down approach.  This is intended to be very flexible so that story can be quickly added and removed as new ideas come up.  At a physical level, a board with post-its work really well.  There are many tools to map digitally and have a preference for FeatureMap and CardBoard, but recommend you research what is best for your needs.  A good article on story mapping is at http://www.thoughtworks.com/insights/blog/story-mapping-visual-way-building-product-backlog.

When it comes to delivering the right solution, knowing your audience down to a specific persona should not be overlooked.  Build model and “edge” audiences to determine all variances of users.  If your target audience are women between 18 and 35 for a cosmetic app, you should still consider including men of different ages that may have a reason to use the app as well.  These personas should be fed into your story board and real users should be found that closely match these personas to validate assumptions and clarify new ideas.

Holding “what if” brainstorming sessions on what and how to build will help promote continuous improvement and recommend using mind maps as tools to visually expand on asking questions on what the ideal solution would do if time, budget and feasibility were not a limitation.

Quick and repeated visualization is a key to delivering a continuously improving solution.  Through low fidelity prototypes, quick assessment and validation can be used for all the previous steps as a visual aid.  As the discovery matures, these prototypes should mature too, becoming higher in fidelity as features are validated as the right ones to build.  New ideas are then introduced at minimum visualization and mature as they are accepted or disappear if rejected.

Finally, to follow the old adage of “What gets tracked, gets done”, Key Performance Indicators should be determined for validating the benefit of discovery.  Ensuring that new features are being modified and improved is necessary.  If the discovery does not create enough change or no change at all, then the discovery track is broken and must be addressed.  Metrics such as the rate of changes, the projected benefits of those changes and the resulting improvements with user adoption (and funding) are critical to tracking.

I’ve heard of cases where daily refinement sessions to properly flesh out the user stories for the delivery backlog, would be held right after the daily stand up, but recommend this be held on an “as needed” basis, which may be every other day, weekly or even less.  However, a regular cadence should be set for each technique to best track progress.  The outputs of the discovery sessions should be incorporated into the product backlog and transitioned to the sprint backlog by the start of a new sprint.

In my next blog, I shall cover my overall opinion of Dual Track Scrum and it’s usage in today’s solution focused industry.

Dual Track Scrum Tools and Techniques

To continue on Dual Track Scrum (DTS), please note at this juncture, I have not put any of these steps fully in practice and so they are purely from a theoretical perspective, although I am aware that DTS pundits such as Aaron Sanders has implemented these tools and techniques within multiple organizations.

To recap, Dual Track Scrum provides an expanded Agile framework for Product discovery that aligns with Product delivery.  This expands on the rather thin structure around backlog grooming and story boarding thus putting more effort and rigor into that process to continuously validate the right solution is being development.

Remember the tenants of discovery are building valuable, usable and feasible solutions.

There are several tools and techniques available with DTS and will cover the overall current state approach with the opportunity canvas.

The opportunity canvas brings detailed clarity of the current product landscape, in an effort to better define what features are the most important in any given solution.  They include:

  • Documenting any assumptions that would be a product killer if proven false.  Be very open and honest on determining these and can be as simple as “Google releases a similar product”.
  • A clear description of the problems the solution is addressing as well as the solution description itself.  This should be high level from an end user perspective as part of a product theme that is frequently tweaked.
  • Describe the users and customers that currently experience the problem.  Who are they?  What is an example persona?  How much does it impact them?
  • How these problems are addressed today?  There is always an existing process and there are usually more than one.  What are they and how much time / effort do they take?
  • How this solution will provide the users new value/improvements?  Time savings?  Cost savings?  Entertainment?  What else?
  • How to measure whether and how much the users would adopt this solution.  Look at what metrics will make a difference in knowing the predicted adoption rates.
  • Determine the adoption strategy to bring the most users on board.  This should be based on the previous opportunity backlog answers to derive the best strategy.
  • Determine any business problems in building and delivering this solution.  Find out the challenges with delivery, marketing, sales, support, etc. with the solution.
  • Identify and measure any changes in business performance metrics for releasing this solution.  Your business will change with the release of this solution and therefore the measurement of success must factor in this solution.
  • The budget must always be considered on how much can be built for a Minimum Viable Product and when revenue must come in to continue building and expanding the product.

I will cover further tools and techniques in my next blog.  A big “hats off” to Aaron Sanders for much of this material.

Dual Track Scrum continued

In my last blog, the topic of Dual-Track Scrum (DTS) was brought up.  That was for my initial impressions.  Now this blog covers a deeper dive.  The ideas behind DTS started with Marty Cagan in 2009 and expanded to being supported by Jeff Patton and Aaron Sanders, among others.

Essentially, Dual-Track Scrum follows core Scrum for the delivery path and expands on the idea of a parallel discovery path for better and more thorough product development.

This parallel discovery path has three core tenants.  The results of the discovery path should be:

  1. Valuable – This is determined by the Product Owner and the UX/UI Expert and validated by the end user community as something they would want.  Discovery of valuable features is critical to successful delivery
  2. Usable – This is determined by the UX/UI Expert and the Development Lead.  The interface for the feature should be built in such a manner than it is as simple as possible that the users love, adhering to Lund’s Usability Maxims (see http://www.simonwhatley.co.uk/lunds-expert-ratings-of-usability-maxims)
  3. Feasible – This is determined by the Product Owner and the Development Lead.  Dream big, but make certain it’s something that can be done with the technology available.

The discovery process has been expanded into more details as opposed to backlog grooming.  In Scrum, backlog grooming is an exercise for the Product Owner to work with the Scrum Master and key team members to validate the backlog priority and prepare for upcoming Sprints.  Per the book “Scrum Essentials” by Kenneth Rubin, this is done on an “as needed” basis.

In Dual Track Scrum, these are broken into regular scheduled meetings similar to Sprint Planning and Review meetings and should be held in a similar cadence.  Attendees include the Product Owner, Business Analysts (as needed), the UX/UI lead, the Development Lead and the Scrum Master (optional).

These discovery sessions go into much further detail of discovery that brings the end user feedback along with tools and techniques to bring out more accuracy and detail on ensure the right product is being built and evolved over time.  Arguably, most critical component of delivering software is not whether it was built on time, on budget or even in defined scope, but whether the end users like and even delight in it, to expand its usage far beyond original expectations, which leads to growth and success.

In my next blog, I will review the tools and techniques for the discovery path.

How to Measure Technical Debt

So one of the biggest challenges I’ve repeatedly heard about technical debt is that although the delivery team knows it exists, there is no easy way to measure the actual cost of technical debt.  However, there are ways to help bridge the unspecific to the specific.

With technical debt, using a financial analysis of comparing addressing the technical debt now versus addressing the technical debt later (at a pre-determined point) will bring useful data to make informed decisions.

So how accurate is that data?  What level of confidence will leaders place on it?  One method to help bridge that trust gap would be to use technical debt evaluation tool like SonarQube that can give detailed counts of technical debt risks.  This can then be used as a “ground level up” method of determining the full cost of fixing technical debt now and given as detailed evidence that this isn’t simply “developer guesswork”.  From organizing the reported debt, the seven axes of Quality reported by SonarQube can then be mathematically estimated and used as supporting evidence.
The example chart gives a comparison that non-technical employees can understand.  This speaks in clear financial figures and can be measured to determine progress and where key decisions can be made.

No longer does technical debt have to be the software delivery department wrestling with business.  There can be a common ground for discussion, collaboration and agreement on how much effort should be made to resolve any accrued technical debt.

Engagement Ceremony

If there is ever an art to delivering technology, it’s about knowing when and how to prioritize events as they unfold.  Some events are small and may only need an email.  Others, a simple test or instant message may do.  At higher levels of modality are direct phone ​calls with screen sharing, Skype, or even face to face meetings.

A recognition of when there is not enough or too much ceremony for the roles involved.  If a dozen emails go by for something that would take two minutes to discuss, then using email is the wrong modality.  Sometimes, that isn’t clear until the communication unfolds, but immediately change the mode if you see that it is dragging down in the form of communication provided.

Also, too much communication can happen.  If a meeting takes up more time than actual doing the work or logging the work is taking up more time than just doing it, the process should be questioned.

​It’s all about business alacrity and a good project manager, and any business professional, should always look for ways to reduce waste in delivery.

Types of Technical Debt

There are three primary types of Technical Debt:

  1. Naïve technical debt
  2. Unavoidable technical debt
  3. Strategic technical debt

Naïve technical debt is common where a specific best practice is not followed due to being unaware of the best design pattern, unfamiliar with naming convention, documentation guidelines or even coding guidelines such as following abstraction in development and having a method serve one purpose.

This happens more frequently with junior level developers, but even the most senior developers can miss things and as a result, create technical debt.  My recommendation would be to use the guidelines in the books “Clean Code” by Robert Martin (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) and “Pragmatic Programmer” by Andrew Hunt and David Thomas (http://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=pragmatic+programmer).  This will include several Extreme programming principles such as code reviews, refactoring, TDD and pair programming to name some.

Unavoidable technical debt will happen due to upgrades in development tools that bring newer and often better ways to maintain custom solutions.  Also, when scope changes are requested during mid development, that will have an immediate cost to it.  What about adding a new feature to an existing web site so it better supports mobile devices?  This too will increase the debt due to rewriting the system to support multiple modalities unless it was designed with that in the first place.

In some cases, like the last example, some unavoidable technical debt is really more naïve technical debt and can be avoided, but the third type of technical debt, strategic, is also avoidable, but instead decided (either intentionally or unintentionally) to be accrued.

For instance, skipping proper quality code practices like code reviews and refactoring in order to make a release by a certain deadline is an example of strategic debt.  Continually placing refactoring tasks at the bottom of a product backlog or nowhere at all is another example of strategic debt.  Strategic debt can be tackled by determining an actual financial cost of the technical debt and presenting to leadership in order to get buy in.  This will be discussed further in future blogs.

Technical Debt Explained

This will be first in a series of blogs.

Technical debt is an interesting term that has been formed in the IT industry in order to have non technical businesses understand the cost of building code in a manner that causes higher maintenance and increased barriers to changing.

Technical debt is intended to have a financial consequence in it’s meaning to recognize it costs businesses tangible money, even though due to it’s complexity, technical debt is difficult to measure and hence difficult for non-technical business leaders to understand.

Technical debt if left unchecked, can make a company that depends on technology drag themselves to a complete standstill and often bring down businesses to liquidation.  Technical debt will increase exponentially over time until it becomes unmaintainable.  It’s happened before, even to the early days of the “killer app” Visicalc that was to be superseded by Lotus 1-2-3 and eventually Microsoft Excel largely due to technical debt.  Only through regular code maintenance (via code reviews, refactoring) can technical debt be controlled over the long run.

​I will cover types of technical debt and what they do in the next blog.

Weatherman and Forecaster

Good project managers (and Scrum Masters) consider themselves like project “weathermen” — they report the current project conditions and forecast the future as accurately as possible.

One important aspect of a weatherman (or weatherwoman) is to escalate quickly and effectively.  The project manager should have a “sixth sense” or intuition when a project is going down a bad path and this isn’t an easy skill to learn.  It truly comes from experience with trial and error.  The key as a Project Manager is to be bold and don’t be afraid to inquire on anything that appears to be going too slow and not clear on progress.  Look at my blog on “The Importance Visibility” for a way to help quickly identify issues.

​However, sometimes only through being the “Larry King” of questioners can a PM dig up all potential issues and address them before they become critical.

Does Empathy Matter in the Workplace?

It’s very common in software engineering to recognize there is a right way to do things and then there is everything else.  Often, that “everything else” is the wrong way to do it.

For instance, using no design pattern or an incorrect design pattern (i.e. a behavior pattern for a concurrency problem) would be “everything else”.

Typically, a team will do things for a very specific and logical reasons.  A Scrum Master should not immediately assume a team member is “doing it wrong”, instead keep an open mind and determine the situation and logic behind what was chosen.  For example, have members of the delivery team hear the reason during a breakout session from a daily scrum.  Then have the team decide if the reasoning is acceptable, keeping empathy and “trying on the other person’s shoes” helps foster trust and transparency.  If they are doing it wrong, at least they can find out why and come to an agreement.

As a servant leader, the Scrum Master should promote and encourage empathy within the team, but at the same time recognize that there is always room for improvement.  There is a balancing act that should be made for picking where to make the most improvements and that can be identified, organized and prioritized during retrospectives.

Keep in mind that not assuming someone is “doing it wrong” without empathy even if they really are doing it wrong.  Give them the benefit of the doubt and show empathy when showing mistakes or oversights to others.  This will build team productivity and as a result, increase velocity and team value.