About This Site

Work experience is dynamic and a person’s Curriculum Vitae should be too.
Professional development happens daily (for good employees) so it should be easy to record and add that development to your professional profile every day as well.
Read more here, I created this blog/website to provide more detail about who I am, what I do, and my professional background.

If I Understood You, Would I Have This Look on My Face? – Alan Alda

I just finished reading Alan Alda’s book on communication and cannot say enough great things. It is insightful while being logical and easy to read. I read it rather quickly as I have a large list of things to do for Lakebed.io  but fully intend to go back and read again taking notes. Right now I am busy implementing empathy and story telling in the communication and layout of the Lakebed app and website.

Riding @ Cadence

People have commented that I ride at a high cadence. While riding at the track started this trend I have actively trained and intentionally continue it. The track is fixed gear bikes; the only way to go faster is to increase cadence.

 

KPI’s

The human body on a bike is a system, just like a car, engine, and road are a system. One can measure power and training effectiveness at various points in that system.

Heart Rate

The heart is the fuel pump so the amount it is pumping is a good sign of how hard the engine is working. Unfortunately the heart can lag behind real power output. So, when doing a really quick, short sprint the rider can get upto max speed and be back down to a slower speed or even stopped by the time the heart catches up and hit’s it’s max.

Power

On the other end of the spectrum there is power output measured in watts. That’s a standardised measure that the cycling industry likes to believe is consistent across riders.

They’ve come to realize it is not consistent so when talking technical power it is often watts/kg or watts/lbs (watts per kilogram or per pound).But, there’ no marketing or device that can measure watts/kg so it’s not widely hyped. So, the first issue with power is that it does not take into account the weight being moved. This is why in vehicles there is the standard “foot pounds of torque”; how much power does it take to move 1lbs 1ft.

There is another, even less discussed inconsistency in power, related to weight, and that is the time component. This is why electric grids measure power by KwH (Kilowatt Hours); how many kilowatts are output for how many hours. For simple math, if I have a light that requires 1 kilowatt to operate, running it for 1 minute is a very different power consumption than 1 hour.

So, when you see the power output in watts from a cyclist ask what the time interval of the power measurement is. Is it being measured every pedal stroke, every second, every minute?

One final note on power is to consider inefficiencies and friction in the system. The simplest explanation is to compare a mountain bike to a road bike. I can get on the rollers on a mountain bike and it takes a massive amount of power to ride at 30km/h. I then get on the exact same rollers on a road bike and 30 is easy. The difference between these 2 bikes are the rider position and most importantly the tires. Now, applying that to the real world, you train on the rollers so know that you need to put out 200 watts to ride at 32km/h in a race but then you go and race and you’re putting out 200 watts but lose the race and average 25km/h. Turns out the rollers had less friction than the road and didn’t simulate wind resistance.

Speed

Conveniently, that brings me onto the next measure of training; speed. Speed still have the same flaws that power has but speed is ultimately what we are training for so makes the most sense to measure. Conveniently speed is also one of the most cost effective and accessible KPI’s for training. Whether a speed sensor on the rollers or GPS within a phone, it is extremely cheap to measure speed and very easy to judge if current speed is adequate/meets training goals.

Other Measures

While the heart is the fuel bump of the body, the muscles are the engine and the veins are the fuel/oxygen line. In sports medicine centres that often measure blood oxygen saturation; the amount of fuel supplied/used by the engine. Another measure could easily be blood pressure. Finally, one could look at the nerve firings or tension/movement of the muscles (for example in an MRI).

These are often costly, weighty, constrict movement, or simply not viable.

Bottom Line

The bottom line, in my opinion, is determine goals and determine the measures that will allow you to train to achieve those goals. Don’t buy a power metre simply because the marketing hype says you need one. I’ve never owned a power metre; the closest I’ve come is the PowerTap HR PowerCal and I have used my wifes power metre to test the accuracy. Even that, simply satisfies my need for data rather than a KPI used for training.

If you are training for racing, setup up rollers or go for a ride as similar as possible to races. Then ride at race speed and distance. Then, when it comes time to race, taking advantage of draft, wind, and racing smart should be easier than training making for a winning combination.

HR Zone Training

I’m not a fan of heart rate zone training.

Typical heart rate zones are:

  1. V. Light, 50-60% of max.
  2. Light, 60-70% of max.
  3. Moderate, 70-80% of max.
  4. Hard, 80-90% of max.
  5. Extreme, 90-100% of max.

The problem here is, for simple math if your max HR is 200bpm then 90-100% is 180-200bpm, which is quite a wide range.

Rather, what I prefer to do is keep track of a few current KPI’s. For example, I regularly track:

  • Current comfortable, all day HR. I.e. the average HR for an entire ride.
  • Current 20min, FTP HR.
  • Current max while cycling.
  • Current absolute max (most people can hit a higher max running than cycling).

I will then complete various training based on those hard numbers. For example, if my 20min FTP heart rate is 170bpm then I might do 20min at 10% above that, which is 187bpm. That is a hard and fast number to hit, there is no variation. The workout might be 10min warm up, 20min @ 187bpm, 10min cool down. If I really want to punish myself I’ll do that twice. It becomes really easy, at 187bpm to ease off when it goes up 188 and push harder when it goes down to 186.

Compare that workout to 20min in zone 4, which could be 20min at 160 or 20min at 180. That’s such a large range that I could complete the same workout at either end of the zone 4 range and get completely different results.

The other issue with using hard coded zones is they don’t adapt and grow as your fitness changes. Whereas if you base it on current data from 3-6 months then +10% is a constant workout above current fitness levels.

Bike Racing

I used to race bikes and a few friends are considering getting into it. I appreciate the opportunity to share my experience and I’m doing it here so it’s easy to searched and referenced later. I sincerely hope this does not come across as egotistical or all knowing. I certainly do not know everything and open to varying opinions, I’m simply recording what has worked for me.

I’ll break down my experience into the following:

Training

Pre-Race

  • 2 Months
  • 2 Weeks
  • 1 Week
  • Day Of

Race

Other

  • Buying a Bike

UI/UX Notes

Personas have many uses including business cases, application design, marketing planning, marketing implementation, etc. While all of those are very different use cases there are many overlaps so it doesn’t make sense to store the same definition in multiple places.
This document is the single, always-updated, reference documentation of the identified persona’s and demographics for Lakebed products and services. With each item it is important to note what it applies to, such as “CIO/CTO – Makes buying decisions for Lakebed application”. On the flip side, the target customer for the independent consulting services is SME’s, which typically would not have a CIO/CTO. Any time new features/functionality are being planned they will be added here to ensure we understand who will use the feature and how.
All the UX courses and material I’ve read says start with “why”. If you understand why a user is interacting with a given website or application then you can design to help them achieve their task. The faster and easier it is to achieve a task the more engaging and, subconsciously,  enjoyable the experience is. Why also drives compelling stories, which humans more often sympathize with so are more likely to feel a personal connection.

What the #$%@ is UX Design?

  • UX definition: takes the user’s needs into account at every stage of the product life cycle.
  • It’s important because:
    • Probably doing it already
    • User-centered design is a process
    • Not that hard
    • Fun & challenging

UX Design Tutorial for Beginners (#1)

  • UX is the beginning of the design cycle.
  • Your purpose is to understand what problem you are trying to solve for your users.
  • UX cycle
    • Research
      • Surveys
      • Customer personas
    • Concept
      • Sketch
      • Storyboard
      • Collaborating on the solution
    • Basic layout
      • No discussion of color, font, etc
    • Test with users
      • Repeat tests until meets user expectations
    • Pass on to UI
  • Definition UCD: User Centric Design
  • UI is where the conversations about images, fonts, colors, and visual identity happen.
  • Button color, could in theory double click-through rate.
    • Simon: the color/design of that button must be something the user intuitively knows is a button. Increasing click-through comes down to verbiage, placement, and content around the button.
  • In large orgs consistent UI is being recognized as vital to the customers perception of the brand.
    • Simon: Consistency creates professionalism, comfort, ease of use, and makes it memorable.
    • Simon: In other words, reduce the wasted RAM for the user remembering the number of layouts that Lakebed users. If everything looks the same (app + website) then it’s easier for the customer to immediately know it is Lakebed.
  • Definition Design Language: Documentation of fonts, colors, icons, and potentially even key words, that can be reused throughout allowing UI to focus on the small details like little animations and instructions.
  • UX research
    • Create personas
    • http://today.yougov.com/profileslite allows you to select user persona items and it compiles and outline of your user.
  • UX Concept
    • Look holistically at the entire journey the customer goes on to use the entire product or service. Understanding the whole allows us to better design/build the component parts.
    • Customer journey mapping
      • The bigger the better
    • Consider find-ability
      • Navigation structure
      • Information architecture.
      • Tree test
        • optimalworkshop.com/treejack
        • Set a bunch of questions and have users find where they think the answers would be.
        • Either by viewing the landing page or by navigating and using menus. Obviously a tree test without interaction is harder.
        • https://www.optimalworkshop.com/treejack
      • Card sort
        • Good for starting from scratch
        • Page information on cards and users sort the cards into where they would expect them to be.
        • Doing this a few times will result in patterns and a consensus.
  • Definition Information Arch: The page structure of the product that allows users to easily find what they want/need or not.

UX Design for Developer Tools

  • Unlike traditional applications,developer tools require focusing on function over form.
  • Designing software for developers is a lot different than designing software for consumers. Each of these programs, or tools, that developers use, have very specific functionality, and when going in to design them, we need to think about what the use is, and how to keep the functionality as simple as possible.
  • Designing development tools requires a different approach than you would normally take from applications used by average users. Again, these types of tools aren’t going to be used by your parents, or your friends, per se, but they’re going to be industry tools that are used by professionals, or internal teams that are designed around specific tasks. For the most part, development tools are not going to be forward facing. That means that they won’t be used by a broader audience.
    • Lakebed.io is in a tough middle ground, similar to Excel it will be used by a wide range of tech skill levels but needs to accomplish and communicate technical tasks.
    • //todo Google ux for technical/comlex applications.
    • //done add component goal to ui/ux docu
  • The person performing the task should be familiar with the task enough, to be able to look at your UI, and understand what they need to do. Any type of documentation, or instruction, should be built into the tool, itself, in order to guide them. You don’t want people having to read a manual in order to use a simple tool.
  • There are lots of development tools to draw a reference from, when designing your own. The best thing you can do, is take the time out, and understand how others have solved problems that you are trying to approach.
  • What if the tool is docked on the side of the screen, or stretched in a way that cuts off most of the UI? While you can add scroll bars to overcome this, you still need to take into account where the user will place the custom tool, and what it will look like when it’s scaled at unintended sizes.
  • What explicit limitations does the program impose on your design?Are you constrained by where you’re going to lay your tool out, or the window that you’re provided? Or do you have free rein to create a tool at any size with any type of layout? The next thing to consider is: Can you build custom designs, or are you limited to what is provided?
  • Once you better understand these limitations, you’ll be able to create tools that make sense in the environment that they’re being used in.
  • While a normal application may have a very intricate design, the tool needs to perform a specific task. This sort of thinking usually goes against what we’re taught as a designer.
    • Good to keep in mind when interviewing/hiring UI/UX people. They may be good at general work but how do they handle business/tech UI/UX?
  • When designing a tool’s UI, think of a hammer or any physical tool you can imagine.These tools have existed in their current form for hundreds of years. While the overall aesthetics may be different from hammer to hammer, functionally they are the same and that’s because the tool has a specific job to complete.
  • It is important to look at existing tools that help people create content for inspiration. Photoshop, Unity, Word, and PowerPoint all have similar UI paradigms. You’ll see quick access tool bars, settings that are buried and out of the way, plus large canvases for people to create content with. Automation tools are simpler, allowing the tool to do what it needs to and get out of the user’s way. Development tools have been refined over the past some odd 30 years of modern computers. At this point, we’re seeing very mature products, so drawing inspiration from current tools and seeing what they do in order to make users more productive is probably the best step in understanding how to build your own tool’s UI.
  • Good UI limits users from breaking the interaction model. If an element can’t be interacted with, it should be disabled. If the element isn’t needed at all, it should be removed. Now the organization of the toolbar is very important. On the left of the Play button are the core system tools.
    • Order of menu items is important.
    • //todo if I am going to rework the menu to allow sub-menus then might be worth adding ordering at the same time.
  • System tools on the left, game editors on the right, and you can preview your work from the button in the middle where your eye naturally focuses.
  • At the bottom of the screen are contextual actions that relate to the task you are doing. These actions are closely tied to the specific application.
    • I wonder if this is a good model? Navigation on the left and actions/tasks always at the bottom (or top). That makes a nice, standard UI that is always the same and always easy to understand.
    • //todo experiment with this in an HTML mockup.
  • By default, this action is hidden, and it only becomes available once you create a special folder inside of the workspace.
    • Seems like really poor design. How do you handle contextual help, how do you handle various naming conventions of the folder, what if someone wants to name the folder something else or share the folder between multiple projects, etc.
  • Since Pixel Vision 8 isn’t able to render enough sprites at runtime to show tool tips underneath the cursor, all of the help is displayed at the bottom.
    • I do like the idea of help content always appearing in the same place.
  • First, which applies to the design of any application’s UI, is that the elements should be colored in a consistent way, but also not to detract from the rest of the application or design that they are surrounded by.
  • While lots of tools are used internally by teams, this may mean that the pressure to have a highly polished design may not be as important.For external facing tools however, your focus should be on the UX and build the design that directs the user towards the task they need to accomplish.
    • Start with the why or the task/goal the user is trying to achieve.
  • Understand the limitations of what you need to design and where your tool will live.
    • Live in an enterprise environment.
  • Make sure to look at examples of other tools that may do a similar thing. Sometimes you’re tasked with redesigning a tool that may exist in another application. Take a look at how it’s built and understand how you can improve it. And, finally, if you’re creating something that hasn’t been done before, try to find a point of reference in something that has been built.
    • //todo find existing similar tools and docu good/bad UI/UX
  • If you take a particular tool and break down its actions,you may be able to find similar tools out there and borrow what works from them and combine it with new elements to build the tool that needs to be created.
    • //todo breakdown Lakebed into it’s components and goals.

UX Foundations: Interaction Design

  • Interaction steps
    • Perceive the opportunity to interact
    • Predict if this is the best path
    • Interact
    • Feedback that something has happened.
    • Learn from the interaction.
    • Remember this interaction and what we learned and if it was successful.
  • UX context
    • Who is doing the interaction and who else may be present.
    • Where are they.
    • When are they performing the interaction.
    • What objects are they using or what tools do they have.
  • //done add overall expectations to each persona and to each page? Or is this already covered in the why?
  • //todo document potential for distractions/interruptions on each page. Document how the page handles those and how it get’s the user back on track.
  • //todo document if voice interaction is likely to happen.
  • The best designs happen when we understand the bigger picture. The various interactions, people, products, etc that go into achieving a goal. This is why it’s better to work with stories than persona’s.
  • Various goals/needs will have various priorities. For example family may pick a familiar travel destination if budget is more important that staying within budget.
  • //todo is it worth defining user urgency on each page?
  • //done is it worth defining amount of time spent on pages?

Top 100 UX Design Tips from a User Experience Master

  • Flow
    • Information/user flow through the site/app
    • //todo outline a common flow for each persona.
      • Start with why and map how long it takes them to achieve that why.
  • Common patterns, don’t make users learn something new.
    • //todo for each element/interaction decide if it’s been done before and if it meets common design patterns (within the app and wider).
  • Warm, bright colors jump out while cold, dark colors sink to the back.
    • This validates my dark grey menu concept
  • Make sure users can complete their primary goal quickly and easily.
    • Landing page should be a short about Lakebed and quick links to common goals; explore data, upload data, admin settings, api query builder.
  • Determine if users will use one hand or two on mobile.
    • Our users will use one hand when reading but the rest is involved and will require two.
  • Always have an obvious way to access the navigation menu on your website
    • On mobile a floating menu button and use #menu id so the button just scrolls to the bottom of the page?
  • Icons should only be used when necessary. Avoid overusing them and do not use them simply for decoration.
    • Completely disagree, I could me an entirely text site if I wanted. Icons break up content, provide quick navigation, etc.
  • EMPHASIZE A POINT OF ENTRY IN THE INTERFACE. Every interface should have a clear starting point. Where should viewers look first? Make it clear.
    • The grey/white does a good job of creating a starting point at the cross hairs.
  • We’re inundated with stimuli. According to gestalt psychology, we try to overcome that chaos by simplifying our perception. We group things. We categorize elements. We look for the whole. Some principles include: similarityproximityclosureconnectioncontinuity, and figure/ground.
  • Our mental focus is finite. Unnecessary elements will deplete those resources. So keep users focused on the important information and functions.
    • Such as only showing information and menu items available to the user.
  • Display Primary Data or Statuses in a Dashboard
    • //todo Add a dashboard to app lading page?
    • //todo add descripton of common elements like help button to the home page?
    • //todo allow closing/minimising various sections?
  • Users prefer different workflows. Create different paths for each goal, and let users choose the most appropriate path for their workflow.
    • Not sure how to incorporate this.
  • Start Progress Bars Above 0
    • Starting at 3% makes the user feel like some is done and it’s moving.
  • Never make the user perform math. Let the computer handle it.
  • Don’t force the user to remember anything. Keep all pertinent information in the open.
  • Reduce the amount of back-and-forth eye motions. Keep all complementary data within close distances.
  • User onboarding
    • //todo as this is not part of the MVP.
  • Don’t tell users to click “Submit” once. If they can click more than once, they will. Instead, disable buttons when users click them. That way, duplicate submissions are impossible.
  • The law of simplicity states we will take complex and/or unknown object and interpret them in the simplest way possible.
    • //todo set minimum spacing between buttons and such and whenever possible simplify UI.
    • //todo also, group common tasks/actions/goals and ensure button ordering is logical.
  •  Affordances – Our impression of possible actions with an object and how much energy it will take. For example, we would push a car with different energy than we would push a door. We know to push a door or slide a screen door based on the design/features/hardware.
  • A physical button has the affordance of being pushed down. A digital button is just a 2D representation but often has depth to imply affordance so users know to push it.
  • As we grow familiar with objects/affordances we build memory of how to interact. Therefore if you are designing a common interface you have more flexibility since users already have memory of how to interact with it.
  • //done identify memory expectations; places were the user is expected to remember information.
  • 2 types of memory, declarative and procedural. Declarative is for knowledge and facts (things we know) while procedural is for things we can do (skills). It is harder for us to explain/outline/define procedural.
  • When users don’t know what to do they employ a trial & error process to figure out what to do. If you see numerous errors or pogo sticking (back and forth between pages) it may imply the user is unclear how to accomplish their goal.
    • //todo identify every place where an action is unclear, assumed, or existing user knowledge is assumed.
  • This product is a joy to use. Dana Chisnell describes delight in a similar way with origins in pleasure, flow, and meaning, and she offers suggestions on how to achieve each. Pleasure arises from beauty, simplicity and the ability to anticipate needs. Flow arises from ease of use, immersiveness, and when people feel empowered. And meaning creates delight with purpose, value, and a personal engagement with compassion and care.
  • This is a great framework for starting from the wider context, then the users goals, and then their motivation (productivity or fun) and then the various mental states driving their motivation.
  • Problem: When we see people not interacting when they can/should or trying to interact when they can’t then we have UI/UX communication problem.
    • Solution: Place affordances, communicate what can and cannot be interacted with.
    • //todo on each page ask testers to identify every possible interaction to confirm if interactions are being communicated clearly.
    • //todo document every possible interaction for every page?
  • //done maybe Lakebed should be described as intuitive/easy rather than enjoyable since it’ll never be enjoyable?
  • //todo change to allowed list and blocked list rather than whitelist/blacklist
  • //todo identify infrequent interactions and document them better.
  • //todo ask testers “what is this similar to” to guide UI/UX design and help content since similar interactions are easier to learn.
  • //todo review and re-review all language for being understanding and accessible. Also consider gender, race, religious implications (female looking account button for example).
  • //todo create site/information architecture
    • include code functions, classes, etc. i.e. //func and //cla and //var and //inp
  • Ways to avoid “dark patterns”
    • Percievable
    • Findable
    • Honest
    • Transparent
    • Notify
    • Clarify
    • Comparison
    • Confirm
    • Reversible (actions)
    • Usable
    • Positive – Only use positive language and actions to ensure users are not guilt tripped into doing something the may not otherwise do.
  • The more time or distance between point of interaction and result the more difficult it may be to learn and/or remember.
    • Young children learn smartphones and tablets so quickly because there is such a small gap between interaction and result.
  • //todo add borders to buttons and make them a fixed width and a gap between multiple buttons.
  • Don’t focus on the most features, focus on MVP features and made them look and work well.
    • //todo document MVP features & functionality and limit to only those.
  • Use motion carefully and only when necessary and purposeful. Unwanted/unnecessary motion can detract from the experience and confuse or upset people.
  • Show error messages as soon as possible (shorten the time/distance between interaction and result).
    • //todo any server side input processing should have corresponding JS front-end.
    • //todo document all input requirements
  • Sufficient motivation or need can override poor usability. If the value of the outcome or the need to complete the interaction is high users will accept more errors/flaws in the UX.
  • 5 UX KPI’s:
    • Learnability – How well can users learn the new system.
    • Efficiency – How well can users complete their interaction
    • Memorability – How well do people remember the product and the UX
    • Errors – How many errors occur, how well do users recover from them, and how well does the product handle errors
    • Satisfaction – How satisfied are users with the result.

7 Tips to Improve Your UX Design Practice

  • Our job is not to follow the path we have created, it’s to follow the path our users want to take.
  • //todo finish reading this article.

Project Management Notes

Large Scale Scrum

  • The LeSS Complete Picture
    • You have one product owner that hovers over all the teams. That shows that you can have one product owner providing work for several teams. Double-ended arrows show how you use daily meetings as a way to coordinate work between the teams.
    • Then, all the teams get together with the scrum masters and product owners and run an overall retrospective. In this meeting, you’ll look for much broader process improvements. When all that’s complete, you have your potentially shippable product. At this point, you can exist the LeSS amusement park and start it all over again in the next sprint.
    • Most other Enterprise frameworks encourage you to scale up. LeSS discourages you from going too big, too soon. That’s why the creators Craig Larman and Bas Vodde often call LeSS the descaling approach. With the descaling approach, instead of scaling up, you should always be looking to stay small.
    • Throughout LeSS, you’ll see this built in conflict between scaling up and the pressure to stay small. The name LeSS makes this conflict clear. It’s large scale scrum so it’s large but at the same time the framework is about LeSS.
  • LeSS Principles
  • LeSS Framework
  • Sprint Planning
  • Product Owner
  • Product Backlog Refinement
  • Scrum Master Focus over Time
  • Potentially Shippable And Definition of Done
  • You have one product owner that hovers over all the teams. That shows that you can have one product owner providing work for several teams. Double-ended arrows show how you use daily meetings as a way to coordinate work between the teams.
  • Then, all the teams get together with the scrum masters and product owners and run an overall retrospective. In this meeting, you’ll look for much broader process improvements. When all that’s complete, you have your potentially shippable product. At this point, you can exist the LeSS amusement park and start it all over again in the next sprint.
  • Most other Enterprise frameworks encourage you to scale up. LeSS discourages you from going too big, too soon. That’s why the creators Craig Larman and Bas Vodde often call LeSS the descaling approach. With the descaling approach, instead of scaling up, you should always be looking to stay small.
  • Throughout LeSS, you’ll see this built in conflict between scaling up and the pressure to stay small. The name LeSS makes this conflict clear. It’s large scale scrum so it’s large but at the same time the framework is about LeSS.
  • //TODO look into LeSS books. They go through good “experiments” to try in the org and evaluate the results. This is a great concept of identifying a single, small change, implementing the change, and evaluating the results. Similar to how S.M.A.R.T. goals that are measurable before you start the work.
  • //TODO read “Designing Your Life” to look at prototyping.
  • Scrum is like your mother-in law, “it points out all of your flaws.”
    • Your retrospectives should take this approach.
    •  You have a small group of people working to create a better process. They should make their failures transparent, so they can easily apply real changes.
  • Larman’s Laws basically say that organizations are implicitly optimized to avoid changing the status quo.Any change initiatives will be seen as the same as the status quo. Culture follows structure. What Larman’s Laws are all saying is that organizations follow the same patterns when confronted with change. 
    • The first is to say that the change is not really a change at all. You’ll see this when organizations adopt the language of enterprise agile, but don’t make any underlying changes. Project managers will become scrum masters and business analysts will become product owners. Then everybody would just go back to doing it the way they were doing it before. 
    • The second is to customize the change until it doesn’t really change anything. You’ll see this when organizations try to change enterprise agileso it fits their organization. The scrum masters will direct the team to use scheduled milestones and product owners will act like business analysts.This is the opposite of what you want in a self-organized cross-functional team.
    • The final Larman Law is about what you could do to fix these organizational changes.
  •  You need transparency and a drive for continuous improvement. If you want to improve the process, you have to be transparent about what doesn’t work. If you hide inefficiencies, then you’ll never be able to run good experiments. Then you have to take what you find out and continuously improve the process, unless you always want to start out with the minimum amount of process. Then when you get to use this empirical approach, you can build it up as you need it. Start with something simple that works, then run experiments and continuously improve until you have the most efficient process.
  • The product owner is one of the most important roles on any agile team.They set direction and also feed the team the highest value work. They’re the one who is ultimately responsible for whether or not the product meets the customer’s expectations. LeSS takes this product owner role and upsizes it to even greater importance. Instead of just one team, the product owner will oversee several different teams. Instead of just working with one set of customers, the LeSS product owner will work with groups of product managers and many different feature teams. The product owner has to manage five key relationships. The first is the relationship between herself and the development teams. Perhaps the most difficult is the relationship between the product owner and the development teams. Remember that the product owner is responsible for distributing the work to all of the teams. That means she has to have a clear and well prioritized product backlog. She’s the only one qualified to explain a function or feature to the development teams. That means that she needs to answer followup questions, and get back to the team if they need clarification.
  • The product owner isn’t the only one who has been up sized to fit the Less framework. The scrum masters also picked up a bunch of new enterprise-level responsibilities. In regular scrum, the scrum master is both a coach and an administrator. One of the founders of the scrum alliance describes them as both a bulldozer and a shield. They protect the team from being overwhelmed and then push through organizational obstacles.
  • They also chime in about how to improve development practices. This might sound simple but in reality, it’s a very difficult role to play. For one, you have two different sets of abilities coming from the same person. This one person has to manage the team while at the same time encouraging them to self-manage. They also have to train the product owner and then later figure out how to improve the overall organization. It assumes that a good scrum master can pivot and seamlessly take on these new areas of responsibility.
  • Sprint Planning 1 meeting where all the teams get together to plan out the work. Instead of having one goal per team, all the teams will share a common Sprint goal. Once all the teams agree on a goal, then they get together and have a Sprint Planning 2 meeting on their own. In Sprint Planning 1, you talk about what the team will deliver. And in Sprint Planning 2, you talk about how your team will deliver. In Scrum, you’ll hear a lot about the What and the How. The What are the functions and features that you’re working on in the next Sprint. The How are the technical details that your team needs to sort out to deliver this product.
    • The What are the functions and features that you’re working on in the next Sprint. The How are the technical details that your team needs to sort out to deliver this product.
    • It’s tricky to think about how this works in practice. So let’s imagine that we were using large-scale Scrum to deliver a meal in a restaurant. Think about how this might work in something like an agile sandwich shop. In the sandwich shop, the What will be what the customer orders, maybe a grilled cheese sandwich and a side of fries. This would be in your Sprint Planning 1 meeting. The How will be how the work gets done. It will be the slicing of the cheese, toasting the bread, or warming up the fryer. This all happens in your Sprint Planning 2 meeting.
  • //TODO develop sprint planning template and go through it weekly with the team.

A Way to Kill Passwords Now

Problem

Passwords are insecure and InfoSec professionals have been calling for the death of passwords for a long time. Problem is, there’s nothing better currently. Things have gotten so bad, TFA/MFA (Two factor or Multi Factor Authentication) are not even secure any more. They’re better than passwords alone but even MFA can be hacked.
One of the [many] problems with MFA is there are too many end points and if any of them get hacked the attacker can get into the system. As we saw in the RSA hack (linked above) if an attacker get’s into the MFA server they don’t need to see the unique code displayed on a phone or key chain, because they can either see that same code on the server or set that code to whatever they want. Alternatively, if they get into the users phone they can see text message MFA codes. Worse yet are users who are mirroring notifications like text messages to their computers as that opens yet another end point for attackers to see the unique codes.
PushBullet is a good example of notification mirroring. I use it, but I only allow certain, low sensitivity data to be mirrored. I know Mac/iPhone is providing this built in now.

Solution

My idea is:

  • When the user goes to login to a network connected device/app/service.
  • The user opens a mobile app that displays a list of phrases.
  • The user selects 1 of those phrases.
  • The user then enters that phrase into the login.
  • The device/app/service then sends the entered phrase over the network to the phone.
  • The mobile app on the phone validates/confirms the entered phrase matches the one selected by the user.
  • The mobile app would also need to send back some sort of token/certificate to confirm it’s own identity.
  • The user is now authenticated and permitted access.

What does this solution provide:

  • By displaying a list of phrases, the user only has to select a phrase rather than enter it twice (once on the phone then once again on the login). The device could even pull a list of phrases from random web search or pull random contact names to ensure the phrase is memorable and easy to enter.
  • The “passwords” being the phrase are temporary, one-time use.
  • The “passwords” by default will have special characters being the spaces between words. Ideally it would also include numbers and/or other special chars.
  • The infrastructure is distributed so the place authenticated is stored and performed is on the mobile device. In order to hack multiple accounts attackers must get on multiple mobile phones.
  • There is not a server middleman performing authentication. When many accounts are stored and authenticated on a server that 1 server can be hacked to access all those accounts.
  • When hardware authentication becomes available (I believe Intel is working on this or may have already done it) then it becomes easy to integrate this as that could be part of the certificate the phone sends back confirming the users identity.

Action

This is not a small scale endeavour. 1 or more large web apps (like Google, Facebook, Micro$oft, or OAuth) would have to implement this in order to convince users to install the app and get the ball rolling. I can conceptualise but it needs someone big.
Google already has their authenticator mobile app.  Flipping things on their head and becoming the primary means of authentication by adding this feature would be relatively easy. Google could just make this another option. The early adopters would be the security conscious but through education & awareness I’m confident the general public would start adopting this rather than the current, terrible password managers.

UPDATED – 26-Jul-2018

After Twitter conversations with OAuth.io I have improved & clarified the idea.
I went to their site on my phone it offered to give it a try via my phone number:
Here’s my thought process on how this would work. You would install the app on your phone, and register your phone number as unique to your phone, the same way Telegram and Line create an account using your phone number as the unique ID. Once the app is installed and setup the user workflow would be:

  1. Go to a secure website, FB for example.
  2. Enter your phone number and click login.
  3. App/notifications pops up on your phone saying “new login from FB, select the passphrase to use”.
  4. User taps the passphrase they wish to use out of a list of random passphrases.
  5. User then enters that passphrase on FB.
  6. FB sends the entered passphrase to the mobile app on the phone.
  7. The mobile app on the phone matches against the passphrase selected by the user.
  8. Mobile app returns true, the passphrases match, or false they do not match.

 

1 Thing

I have a new rule for my life: Do only 1 thing at a time. This is 50% recovery from my accident and 50% recognizing that multi-tasking is inefficient.
Now, I will do 1 thing and do it until completion, then move on to the next thing and do that until completion. If someone comes to me with a new task, it either goes on the task list or usurps the one thing and I do the new task until completion. This prevents multi-tasking and forces project management; is this new task the most high priority or do we evaluate priorities after the current high priority is complete.
My current 1 thing is the book Healing Anger by The Dalai Lama. Once that is done I expect my next 1 thing will be a UX course and then a jQuery UI course.