Posts on Jun 2015

Mos def Scrum.

High Intensity Management: The Original Scrum

High Intensity Management: Mos def Scrum

What’s the scrum?

Scrum’s focus is “on the business needs of projects when developing products and services”1. As a technology company, LISNR has embraced the need to produce deliverables. This is not particularly surprising that scrum became the approach for this, as it is common at other organizations of similar age and personnel size. So the point of this manifest is to explain the proximity between the scrum methodologies and the United States (US) Army’s reconnaissance planning methodologies when working with small, distributed teams.

Scrum is an agile methodology, meaning it is meant to be flexible. Although it is not the first methodology to attempt to encapsulate flexibility, it is one that has some principles that are perfect for producing products rapidly and in an iterative way. Tom Poppendieck (2003), the author of The Agile Customer’s Toolkit, expressed this as the following seven principles2:

1. Eliminate waste – add value not inventory
2. Amplify learning – as a repetitive process
3. Manufacturing postponement – delay decisions until the last second (when necessary)
4. Deliver as fast as possible – Iterative timeframes
5. Empower team members – training, trusting, and leading
6. Build integrity – perception versus reality
7. Avoid sub-optimizing – understand the whole business need

(List paraphrased from Scrum Project Management, 2003)

         The seven principles fit the needs LISNR had in order to solidify the product and the go-to-market strategy in the most disruptive way possible. These principles were explained better to me than what is written in FM 3-20.98 (Reconnaissance and Scout Platoon) by Major Ryan T. Kranc while he served as the Commander of L Troop, 2/16th Cavalry Regiment. He explained these principles as “focus, tempo, engagement, disengagement, and displacement criteria” (personal conversation, 2008). He also wrote at length about these concepts in 2008 in the November – December issue of Armor Magazine3.

Let’s correlate the scrum out of US Army doctrine.

         Every one of the Poppendieck principles has a focus, tempo, engagement, disengagement, and displacement criteria. That is what makes it flexible during concurrent projects and that is why scrum is extremely flexible despite being somewhat standardized in its loose constructs.

Focus

         Here is the step through of the principles and their correlation. Each phase needs a focus that meets the intent of the business model. Without understanding the intent, then each phase is misguided in the type of goals to be planned and produced. The idea is to narrow the scope of the information needed to the minimal amount necessary to complete the task for the level of the personnel involved. Not all levels of participants need to know the whole picture in order to attain a productive focus to complete the project. This is all based around information relevancy for the level of personnel involved.

Tempo

Each phase requires a tempo. Tempo is the amount of speed and detailed effort to establish a given phase. The eliminate waste phase is a deliberate process, meaning that the tempo is slower due to careful detailed analysis of the requirements of the phase. The inverse is the delivery phase, which is rapid and forceful since the requirements should already be specified upon reaching this phase in order for execution to take place effectively. Other phases may be one of these two options or anywhere in between in the amount of speed and detail to be consumed.

Engagement

Engagement criteria in scrum phases boils down to the rules around a task. Just as a Cavalry Scout has to sometimes let opposition go past their position in order to canalize them before letting them be crushed by the main effort, so must a Software Engineer sometimes let minor bugs slip past in order to eliminate other issues that can derail the project as a whole. These minor problems are still reported and annotated for future projects as specified in the engagement criteria.

Disengagement

A disengagement criterion is a set of rules of when to stop working on an objective for a Software Engineer participating in scrum. An example is when a 2-point story with a mal specification becomes a 5-point or an 8-point story. In this example, the Engineer should cease-fire or continues to over-watch on the objective/ story and report the issue to the Scrum Master for follow-on guidance. Such guidance may be to continue to work on the objective, come back to the objective later, request support for the objective (pair programming), and/ or to follow the displacement criteria. There are rules to how to disengage from a task in scrum as well. The teams, in order to breed integrity and empowerment, define the engagement, disengagement, and displacement criteria for each sprint during the sprint planning meetings.

Displacement

In scrum, the story may be pulled from the sprint just as a Scout may be pulled from an objective and reorganized for a follow-on assignment. Often when a story becomes too much or is later determined as non-critical to the business needs then it can be displaced from. The displacement criteria are the rules in how the displacement occurs. Does the developer log the issue, results, and/ or findings somewhere? Or is it an open abandonment, such as “won’t fix” requirement added to the story? Again, to breed integrity and empowerment, the employees are given the focus to make these decisions in consensus, while also being in accordance with the business model’s intent.

Scrum is a fancy word.

         As displayed by this extrapolation between reconnaissance planning criterion and scrum, it can be noted that scrum concepts are nothing new. But since this is the newer word to decorate these methods for Software Engineers, Project Managers, and the like in a way that is applicable to their work flows for lean success, I believe scrum is perfect for any organization.

We mos def scrum.

Scrum has been proven to be effective for LISNR. LISNR has been able to maintain focus despite being small, often distributed, and made us completely disruptive to our industry. This clear focus of intent to be THE Smart Tonetm provider for all content delivery services has helped us create the tools to provide that service in an iterative way. As we continue to improve our technology in this way, we do so with the appropriate tempo over a 10-day sprint with clearly defined criterion for each story as to what the engagement, disengagement, and displacement criteria is. Major Ryan T. Kranc has not only made this concept intuitive for the US Army, but also allowed this current civilian to apply and recognize these principles within my own workflows and that of other Software Engineer’s workflows for the betterment of LISNR’s innovations. We are mos def scrum.

Sources

1Pries, K. & Quigley, J. (2011). Scrum Project Management. Boca Raton, FL: Auerbach Publications.

2Poppendieck, T. (2003). The Agile Customer’s Toolkit. Poppendieck.LLC.

3Kranc, R. (2008). Fort Knox, KY: Armor Magazine, Retrieve from https://www.benning.army.mil/training/eArmor/2008/NOV_DEC/ArmorNovemberDecember2008web.pdf.

LISNR is a high frequency, inaudible technology; a new communication protocol that sends data over audio. As the leaders of the Internet of Sound, we use inaudible sound waves called SmartTones™, to transmit information.  LISNR essentially transmits customizable packets of data every second that enable proximity data transmission, second-screen functionality, authentication and low-fi device to deviceconnectivity on any LISNR enabled device.  We enable this functionality better and more efficiently than bluetooth (proximity), ACR (2nd Screen), and NFC/RFID (authentication). As an integrated software partner, LISNR can power devices to connect with world around better than ever before.

Eye of The Beholder

Screen Shot 2015-06-17 at 1.25.33 PM

Those who have worked on a user facing application will understand one of the larger challenges is when you have someone outside the process testing or using the application. You’ll watch them, clicking or tapping: exploring the twisty corridors of the user interface. Things might seem fine until you watch them do something you didn’t expect they would try. Why are they interacting with that? Don’t they know that only moves horizontally? You might feel obliged to speak out and mention they need to do something else. Maybe you do. After that, the assumption usually is that you must have not addressed that use case or made something visually apparent. Most of the time those in that position assume that, because the user is not interacting in the same patterns as the user interface was designed to read, it must mean that interface is wrong. I’d like to explore the possibility that they might be wrong.

An important pillar of interface design is to bridge the gap between the information that needs to be displayed and the path the user needs to take to interact or direct this information. You’ll find tasks that are measured to be more important to the general user are designed to be more prominent. Organization is important too. The interface to connect to a WiFi network will want to have connect/disconnect buttons nearby the network name so to convey to the user that the button works on the network it is near. But, despite all these rules people tend to follow and all the feedback taken from users to gauge how the application should interact, is it taken into account that the user might be wrong?

Now, you might think at this point I’ve gone off the deep end by suggesting such a thing: most applications are made by businesses, who naturally realize they need to make users want to use their application enough to pay them for it or a service. If they do not have something a user will understand how to use, the business is in trouble. This is a necessary direction to go most of the time, but if you want to disrupt the norm or are idealistic about human-computer interaction, this is another side to consider.

The reason the user may be “wrong” is that the user will only be able to understand interface elements they have seen before. This explains why many full-featured designs aim to take cues from nature: something almost everyone will experience in some way. If you build a new kind of interaction or one they are not familiar with, they will exhibit the confusion that is normally viewed as a negative reflection on the user interface. Most of the time, new interface elements are tackled in better designed interfaces by having some interface “guides” point or demonstrate to the user to how they can interact. Does this mean every interface element needs to understand how to promote itself for when someone hasn’t seen an interface before? Going down that route is a complex effort that could cause more problems with interaction if not taken in smaller doses. How do you decide what is the “right” way to do something? Is it the way the most number of people will expect, is it a platform expectation, is it something you think makes sense in context, or is it based on other interaction patterns being used throughout you application? Some of the ways just mentioned will be the same thing, but sometimes they are not.

Now, if you aren’t examining what the user is expecting to make interface decisions, how do you decide how to design the user interface? I’m not sure I have a good answer to that question, but let’s look at how some have dealt with these kinds of problems. Microsoft has recently spent a lot of time of designing interfaces. Microsoft spent a lot of time trying to make a touch interface on Windows work and was initially met with lots of upset users. Does that mean their design was wrong? They seem to think they mostly weren’t wrong as their next interface revision has kept most of the design changes around in some fashion. Users are also complaining less about the design. As I have worked on some user facing applications myself, I’ve made decisions on an interface that seemed to make sense to me only to have other people say it didn’t work as they expected. Upon testing things myself, I can see reasons for doing both interfaces.


To swipe or not to swipe…

It is beginning to sound like interface design is near impossible to get right, as people will only consider the design “good” if they already know of it or is close enough to something they know. Is “good” interface design really so malleable or is there such a thing as absolute “good” interface elements?

LISNR is a high frequency, inaudible technology; a new communication protocol that sends data over audio. As the leaders of the Internet of Sound, we use inaudible sound waves called SmartTones™, to transmit information.  LISNR essentially transmits customizable packets of data every second that enable proximity data transmission, second-screen functionality, authentication and low-fi device to deviceconnectivity on any LISNR enabled device.  We enable this functionality better and more efficiently than bluetooth (proximity), ACR (2nd Screen), and NFC/RFID (authentication). As an integrated software partner, LISNR can power devices to connect with world around better than ever before.