Tag Archives: agile

IoT Course Week 8: Intro to Mobile Development

Internet of Things Course

For a change of pace, we are taking a step back from the cloud -> server model we have been working so diligently on, and instead turn our eyes towards mobile. As more and more people around the world enter the global smartphone market, the Internet of Things space is becoming increasingly reliant on smartphone interfaces to control connected devices. This is because the components native to the smartphones that many of us carry, are simple and effective media of interaction with the connected world around us.

The Mission

The goals of week 8 are to provide an introductory course on modern mobile development, in both native iOS with Objective-C and native Android in Java. This week will set up a user interface to control the LAMPi, which next week, will be extended to operate over Bluetooth.

iOS

While the students were almost equally divided on Android/iOS, most of the students utilized Mac laptops, so we made the pairs heterogeneous as each pair had to build the app for both platforms.  This is necessary due to restrictions that Apple places on its developers, where software meant to run on the iOS platform must be developed on a machine running some recent version of OSX. Students were led through the creation of a project in Xcode, and some initial configuration that Apple requires developers to follow in order to sign and run their code. Students used Xcode to create a single view project, and they got to work.

Working in Interface Builder and a UIViewController, students were guided through adding and connecting a UISlider and UILabel to an IBOutlet.

“`

#import <UIKit/UIKit.h>

@interface LampiViewController : UIViewController

@property (nonatomic, strong) IBOutlet UISlider *slider;

@property (nonatomic, strong) IBOutlet UILabel *label;

-(void)onSliderChanged:(UISlider*)sender;

@end

“`

“`

#import “LampiViewController.h”

@interface LampiViewController ()

@end

@implementation LampiViewController

– (void)viewDidLoad {

   [super viewDidLoad];

   NSLog(@”slider: %@ \n label: %@”, self.slider, self.label);

}

-(void)onSliderChanged:(UISlider*)sender {

   NSLog(@”slider changed”);

}

@end

“`

A this point, a slider appeared on the screen that could be interacted with to update the label.  However a problem existed when the screen was rotated on its side.

Screen Shot 2016-04-05 at 9.36.44 AM

As can be seen, the slider and logo fail to expand out when the screen changes. This can quickly be remedied by utilizing one of the much loved nuances of Xcode’s Interface Builder, which is defining constraints on the views.pin_image

And once applied, everything came together. As can be seen here, the iOS Simulator is capable of fluid rotation from portrait to landscape, without any upsetting of the slider position.

with_constraints

Android

Android development, unlike iOS development, is capable of running on a much larger swath of machines. Since its introduction, Google’s Android has been open sourced and designed to run on the Java Virtual Machine (JVM).

Students began by downloading Android Studio and the latest Android SDK Tools. Using the Android Studio Interface, students created a new Android Studio project, allowing the template to be generated for a blank activity. Android Studio wants to get developers started quickly. They offer some shims that help this process. Because our project will be full of custom layouts and widgets, choosing a blank activity is the ideal scenario. After all was said and done, students were left with an application containing one activity.shim_project

Students were given a custom UI Widget in order to define a consistent slider for the class to use. The slider was added to the created activity layout in the XML here:

“`

<?xml version=”1.0″ encoding=”utf-8″?>

<RelativeLayout xmlns:android=”http://schemas.android.com/apk/res/android”

   xmlns:tools=”http://schemas.android.com/tools”

   android:layout_width=”match_parent”

   android:layout_height=”match_parent”

   android:paddingTop=”@dimen/activity_vertical_margin”

   tools:context=”.Lampi”>

 

   <View

       android:id=”@+id/bar”

       android:layout_width=”match_parent”

       android:layout_height=”10dp”

       android:layout_alignParentLeft=”true”

       android:layout_alignParentTop=”true” />

 

   <com.leandog.widgets.hsv.sliders.HueSliderView

       android:id=”@+id/hue_slider”

       android:layout_width=”match_parent”

       android:layout_height=”wrap_content”

       android:layout_alignParentLeft=”true”

       android:layout_alignParentTop=”true” />

</RelativeLayout>

“`

and when rendered by the running application it looked like this:

hue_slider_example

An event listener is added to the HueSlider, which tells a changeColor to run whenever the slider is interacted with.  It also allows the slider to initialize to a certain position or color, which will be useful when starting and restarting the LAMPi appication.

“`

package com.leandog.lampi;

 

import android.os.Bundle;

import android.support.v7.app.AppCompatActivity;

 

import com.leandog.widgets.hsv.sliders.HueSliderView;

import com.leandog.widgets.hsv.sliders.OnSliderEventListener;

 

public class Lampi extends AppCompatActivity {

 

   HueSliderView hueSliderView;

   View bar;

 

   @Override

   protected void onCreate(Bundle savedInstanceState) {

       super.onCreate(savedInstanceState);

       setContentView(R.layout.activity_lampi);

       bar = findViewById(R.id.bar);

       setupHueSlider();

   }

 

   private void changeColor(int color) {

       bar.setBackgroundColor(color);

   }

 

   private void setupHueSlider() {

       hueSliderView = (HueSliderView) findViewById(R.id.hue_slider);

 

       hueSliderView.setOnSliderEventListener(new OnSliderEventListener() {

           @Override

           public void onChange(int color) {

               changeColor(color);

           }

 

           @Override

           public void onSliderInitialized() {

               changeColor(hueSliderView.getHue());

           }

       });

   }

}

“`

Where we end up

The homework for this week was to follow the patterns of user interface and code interaction just demonstrated, and build a fully operational user interface for both iOS and Android. These user interfaces will essentially mirror that which we have already built on both the LAMPi screen, and the web interface.

iOS Simulator screen capture:

ios_assignment

Android Emulator screen capture:

android_assignment

What is next!

Next week we will add the bluetooth functionality that connects our devices directly to the bluetooth hardware running on the Raspberry Pi controlled LAMPi.  For the sake of brevity and focus, from this point onward, mobile development will be done primarily on the iOS platform.

Climbing Mountains With Agile Methods

Agile methods strive to break large goals into smaller achievable parts. In this post we will cover some high level concepts that have made it easy for us to achieve some big goals for our clients.

agile goalsBig goals, in many ways, are like mountains. They are daunting, arduous to climb (and well worth the view from the top). They capture our imagination and inspire bold action in ourselves and others just by being. Many gaze up at their peaks determined to reach the summit, but all too often, fall short for one reason or another.

Our struggles maintaining motivation when taking on large initiatives often stem from over-focusing our energy and attention on the end result, rather than the next step we must take to get there. We can get so overwhelmed by the sheer size of what lies ahead, frustrated by slow progress, and tripped up by unexpected pitfalls, we become demoralized long before we ever get close to the finish line. When this happens, it is because we have forgotten that big things are never accomplished with a single herculean effort; rather, they are overcome in progressive iterations – tackling a series of smaller tasks that bring us one step closer to the summit.

Agile Goals

When you break large objectives into small, measurable, achievable tasks, suddenly the mountain doesn’t seem so insurmountable. You start to think, okay, yeah…I can do this. Taking the journey step-by-step will will allow you to adapt when plans shift and celebrate milestones along the way. Side note: Seriously, don’t forget to celebrate the milestones – they are critical for maintaining morale and reinforcing positive change. This isn’t to say you should allow yourself to lose site of the big picture, just don’t let the magnitude kill your momentum.

This deliberate, iterative approach to “mountain” climbing is the same one we teach our clients and practice ourselves here at LeanDog. Here’s how it works: when someone comes in looking for help, whether for coaching or a development project, we always start by first assessing the situation. We explore every facet of their initiative to define where it is they are trying to go, the resources they have to get them there, and the struggles they may be facing. We also challenge assumptions and test hypotheses to uncover areas of risk hidden in their way. In doing so, we break their mountain down into a big pile of small, achievable objectives. We collaborate with them to prioritize those objectives and, through progressive iterations, we are able to carve out a path up the mountain together. The result is a clear direction, measurable progress, mitigated risk, and the overall feeling that yeah…we can do this.

By breaking down your large initiatives into smaller, achievable steps, challenging assumptions, celebrating milestones, and prioritizing tasks of highest value, you’ll find that what once seemed to be an impossible undertaking, is anything but. Before you know it, you’ll be enjoying the view from the summit and gazing confidently toward your next mountain.

How do you and your team achieve your biggest agile goals and initiatives?

To learn more about how Agile processes can help you climb your mountains, download a free copy of the LeanDog Agile Discussion Guide.

IoT Course Week 4 : Introduction to the Cloud

IoTBackground

It is week four of the IoT course and students of Case Western Reserve University have successfully built their very own touch-screen controlled LAMPi’s. This week students will take a major step towards greater functionality and control.

Demoing Previous Week’s Work

Students began the week by demoing their assignment from the previous week – building a  Python service to act as an abstraction layer between the LAMPi hardware and the various user interfaces. You can check out the post for the week here: Week 3

Learning IoT the hard way – Why we are not using an IoT platform

This week’s lecture started with a brief introduction to available commercial IoT platforms. For this course, students will forego working with a commercial IoT platform, and delve directly into Amazon Web Services. By having the students build their own platform on top of AWS, they will gain a greater understanding of the various components involved, which will allow them to make informed decisions when dealing with commercial IoT platforms in a professional capacity.

To the cloud – Amazon EC2

The cloud! Yes, that cloud. Those nebulous servers in the sky. Students will be maintaining their cloud connectivity using AWS Elastic Compute Clusters, or EC2.  At the beginning of week 4, the services running on LAMPi were locally controlled through a MQTT broker called Mosquitto. The goal for this week is to bridge the MQTT broker running on the Raspberry Pi, to another MQTT broker running on EC2. Luckily for our students, with a little configuration, Mosquitto offers this functionality.

Students began by setting up free tier EC2 instances running Ubuntu. After configuring AWS security groups for their instances, they installed the Mosquitto command line utilities mosquitto_pub and mosquitto_sub.

Bridging between Mosquitto brokers is done through editing configuration files on both the host and the remote. When bridging, the user can configure what topics are transmitted in which direction — for instance, we can specify that only lamp state updates go out to the cloud, and only configuration changes are received from the cloud. Any topics not configured do not get to cross the bridge and will remain on the system they originated. The configuration to the remote follows the structure here:

connection <bridge_name>
address <IP>:<port>
topic <pattern> <direction> <qos> <local-prefix> <remote-prefix>
remote_clientid <remote_clientid>
cleansession <true or false> (defaults to false)

Following this pattern will open the bridge between the MQTT brokers. From that point, depending on the configuration of “In” and “Out” directions, messages will be passed from the appropriate publisher to its subscribers.  It is worthwhile to note that, although the broker is now up and running on EC2, there is not yet any functionality beyond simply passing messages. This will be the topic of the next lesson. Part of the reason for this is that configuration of Mosquitto can be complex and that complexity is compounded by the configuration of the whole system — security, supervisord, pigpiod, etc. By doing this in steps, we can test our system at each step of the way. For now, a few more steps are required to ensure our path from the Raspberry Pi and EC2 instance remain unbroken.

Unexpected Events – Last Will and Testament

The MQTT specification defines a mechanism called a Will. In the event that a client disconnects unexpectedly the MQTT server will publish the Will message. The students will use this mechanism to announce the connection state of the lamp. In Python, the code looks like this:

       client = mqtt.Client(client_id=CLIENT_ID, protocol=MQTT_VERSION)
       client.will_set(get_client_status_topic(CLIENT_ID),
                       “0”, qos=1, retain=True)

Service management – Supervisor

The students were introduced to a Linux service called Supervisor which is responsible for ensuring that all of the processes that we care about stay running. If the LAMPi is unplugged, or the cloud service restarts for some reason, a proper Supervisor setup will ensure that all systems are restarted and running. These concepts were applied to the LAMPi’s by creating a Supervisor D configuration file that will keep the lamp service and the UI running.

What is up next?

Next week, the students will be introduced to web interfaces and the servers that host them. They will be utilizing HTML, CSS, Javascript, Websockets, and NGINX to create a web interface to LAMPi. This will build upon the the work they accomplished this week by hosting the web server on their EC2 instance.

Professional Development Hack Days at LeanDog

There are a number of fields in which ongoing professional development is not simply a job requirement, it’s the only way to stay relevant in an industry that is perpetually evolving. The highly technical world of software development is no exception. Coders, designers, and engineers of all programming languages must continually update their skill sets just to keep pace in a field where technology evolves seemingly overnight and market trends are constantly shifting underfoot.

As essential as this constant professional improvement is for the individual developer, it is absolutely critical to the survival of a software studio. Design and delivery studios depend on competent, creative, T-shaped craftsmen to drive innovation and produce cutting-edge products. However, in busy shops like LeanDog, where developers are routinely tackling complex scenarios, it can be a challenge to find time to pick up a new skill or enhance an existing one.

So how do you help your development team diversify their skill sets when client demands dominate the majority of their time? One way is for leadership to actively create opportunities to learn something new in an environment free of the pressure to “get it done.”

So that’s what we did! Last Friday, the LeanDog Studio took a break from their many projects and joined forces to try something new: a Professional Development Hack Day.  This session had three overarching goals:

1) Learn something

2) Share Something

3) Have fun

Prior to Hack Day, the Studio came together and pitched nine project ideas. They then took a vote and ended up choosing four to pair on:

  • Unity as a rapid-prototyping tool
  • Indoor navigation with iBeacons
  • Deployment pipeline with Docker
  • Conference outline – UX Survival in Agile

After the monthly company meeting, studio members teamed up with co-workers they are not normally pairing with and spent the next four hours “nerding out” (a highly technical industry term) on their respective projects, the summaries of which are listed below. At the end of the day they regrouped for a Show and Tell and voted on which project took “Best in Show”.  Everyone had a blast and learned some pretty cool stuff in the compressed (but relaxed) format.

The Projects:

Unity as a Rapid-Protoyping Tool

Will Kesling pitched this idea to look for alternatives for prototyping game mechanics and solutions.  Our current tool for this is Gamesalad, which makes it easy to build quick prototypes, but limits our ability to modify the generated code for our purposes.  The goal of this session was to attempt to build a mini-game that would better suit our current prototypes.  Will Kesling, Bill Holmes, and Eric Hankinson teamed up and found that Unity was a very cool and powerful tool.  They built an interactive 3D world with converted 2D objects.  It was great to be able to write C# to handle some mechanics.  However, Unity is not well-suited for rapid prototyping.  The team suggested looking more into 3D Unity as a production-level framework and perhaps trying again with 2D Unity to see if it’s a better fit.  The team recommended starting with the asset store when you start a new Unity project. 

Indoor Navigation with iBeacons

Gary Johnson pitched the idea of mapping the boat (our office) and using locators on people and items.  Besides being cool, exploring this technology would help us understand installation type projects, like museums and trade shows.  Mike Kvintus, Nick Barendt, Paolo Appley, and Carl Shotwell ended up teaming up to map the boat using the estimote beacons we had on hand.  The team deployed the beacons, mapped the area, and started a swift app to display locations.  They found the estimote service and SDK to be difficult to use.  The software was buggy, slow and inconsistent.  Additionally you need at least 4 estimotes to map a room and they come in packs of 3.  The estimote mapping software was not a big fan of the irregular shape of the boat.  The team suggested getting more beacons to see if a larger area could be mapped and investigating alternative iBeacon technologies.

UX Survival in Agile

Nicole Capuana pitched working on a conference talk for Codemash that would describe how UX best fits into Agile Software Development.  The ultimate goal is to create a talk that would be reusable with multiple perspectives.  Steve Jackson and Charlotte Chang joined Nicole on brainstorming and talking through ideas that would make this a useful guide for UX practitioners in multiple uncomfortable situations.  The team also worked on a talk Charlotte is preparing on Software Development Lessons Learned from Industrial Failures in the 1980s.  The session was very productive and the team recommends that all speakers try to get differing perspectives for that post-abstract phase.  This collaboration helped raise the bar on what a really excellent audience experience could be.

Deployment Pipeline with Docker – “Best in Show”

Nathan Wallace suggested building multiple environments with Docker and testing each one with our continuous integration server.  If successful, this would apply to many of our current projects, allowing us to easily build and deploy new fully tested environments for all of our integration points (along with our tested code).  It also has the potential to reduce our need to configure and setup environments for our CI itself.  Nathan and Chris Nurre teamed up and were successful in building a Docker image for a vanilla rails install. With each pushed commit, a new environment was produced.  The team found that installing Docker on our heavily mac-based infrastructure was difficult, but was otherwise happy with the tool.  Their recommendation was that all of our web-based projects should default to using a Docker file for CI and that it would be useful to further investigate the Jenkins-Docker integration, as well as deploying the images using a Docker registry.

By taking a small break from “getting it done” and creating an environment focused solely on learning something new, we were able to provide everyone an opportunity to relax, expand their horizons, and bond with their co-workers. Overall, LeanDog’s first Professional Development Hack Day was a rousing success and the team is looking forward to coming together next month to do it again.

tumblr_inline_nx7cuomCMg1tc23o0_540

tumblr_inline_nx7cuoxAdW1tc23o0_540

Building a Raspberry Pi Controlled Desk Lamp with LeanDog and CWRU

As mentioned in a previous post, Nick Barendt and the LeanDog Studio have teamed up to offer a Connected Devices Workshop for Case Western Reserve University (CWRU) students in response to a trend of increasing interconnectivity in product design known as the Internet of Things (IoT). In this course, students are gaining practical experience building a proof of concept system: a physical device, web integration, and mobile development.

The goal of the course is to familiarize students with each component in a complicated system, providing them with a systems level understanding of all the technologies and disciplines that go into creating a connected device

Follow along with us as our students create their very own web-controlled desk lamps, which we’ve dubbed “LAMPI” [lamp-ee]. By the final week of the course, students will possess enough experience to build their own prototype for a new product or service, or confidently dive deeper into any of the software components for further study.

The class is comprised of mostly Juniors and Seniors in Electrical Engineering, Computer Engineering, and Computer Science.  That means that there is a broad range of electronics and software development experience in the class, at skill levels ranging from beginner to advanced.  To address the variety in skill sets and levels, students are working in pairs on the lab assignments, switching up pairs each week. This method of “pairing” is widely used in the world of professional software design and a is a key practice in the LeanDog Studio. We will dive a bit deeper into the benefits of pairing in a later post.

Now, without further ado…

Screen Shot 2015-10-15 at 3.08.16 PM

Building a Raspberry Pi Controlled Desk Lamp

CWRU’s IOT course kicked off by getting students familiarized with:

  • Burning an SD card image with Raspbian (a variant of Debian Linux)
  • Booting up a Rasberry Pi (a tiny and affordable computer, with a rich community of hardware and software support)
  • Connecting to a serial console (UART)
  • The basics of Pulse-Width Modulation (PWM)

On the first day of the course, students cracked open their shiny new Raspberry Pi’s, added WiFi adaptors, SD cards, a custom interface circuit board, and serial cables; attached them to the lamp base, added power cords and an LED ribbon cable, and connected the devices to their computer with a serial (UART) USB cable.  While UARTs are “old school” (RS-232 anyone :-), they are still common on embedded devices, and are often your last ditch, never fail, connection option.

Screen Shot 2015-10-15 at 3.10.43 PM

Students connected their LAMPIs to the CWRU Campus Network, and learned how to remotely connect to a Linux shell on the Raspberry Pi with SSH, a basic tool for modern, distributed software development.  

The class was then tasked with installing the pigpio library, for interacting with the General Purpose Input/Output (GPIO) digital pins on the Raspberry Pi.  Three of the GPIO lines are connected to a custom interface board that has three high-power drivers to control a 3W Red Green Blue (RGB) LED.

Screen Shot 2015-10-15 at 3.13.21 PM

Turning a GPIO line on enables the driver circuit for that LED color channel, lighting up that LED color.  By using Pulse-Width Modulation (PWM) support within the pigpio library, the intensity of the LED can be varied from completely off to full brightness by changing the duty cycle of the PWM command.  By varying the intensity of three LEDs, the RGB color (or, equivalently, the Hue and Saturation) can be varied.

By the end of the first week, students were able to write a simple Python program to generate light by cycling through the primary colors (Red, Green, and Blue) and White.

FINAL THOUGHTSScreen Shot 2015-10-15 at 3.21.33 PM

Why a Raspberry Pi?  Honestly, it is overkill for a desk lamp.  We’re actually using a Raspberry Pi 2B, which is 900MHz Quad-core ARM Cortex-A7 processor with 1GB of RAM.  That’s a crazy amount of computing power for a desk lamp.  But, it does allow us a few simplifications for the course.  Typically, embedded devices, like a “smart” desk lamp, are develo   ped using the C programming language.  Teaching the students C would take a few weeks, plus the additional complexity of working in a cross-compiled environment (i.e., writing the software on their Intel based computer to run on an embedded ARM processor).  We decided to trade that time off to expose the students to other important topics in the Connected Device space and use a high-level language, Python.

Why Python?  Python is fast to learn, runs in lots of different environments (embedded, cloud, etc.), and has a huge community of open source development projects.  While interpreted, Python is relatively efficient, and has solid support for integrating with low-level libraries (i.e., those written in C) for hardware interaction.  An additional bonus is that later in the course, when we move to the “cloud” and web development, some of the Python experience can be transferrable.

Why a desk lamp?  It is unclear if the world really needs a web and smartphone controlled desk lamp.  What we need for the course is a device to motivate the exploration of the IoT / Connected Device ecosystem (embedded, UI/UX, Cloud, Bluetooth Low Energy, mobile, etc.), and even a simple desk lamp provides enough complexity to make that exploration interesting.  Light is also a primal and fundamental aspect of our lives. After all, it was our mastery of light and tools that arguably began man’s journey towards technological advancement. Therefore it is fitting that as we begin to explore this new evolution of product design that we bring our modern light and tools together again to help “light the way,” even if our guiding example takes the form of a humble desk lamp.

Stay tuned for more as the course progresses and we drill down into the many interesting and challenging concepts that make up the Internet of Things.

Coming soon: The creative design process behind the LAMPI’s unique shape.

LeanDog and CWRU Team Up For Connected Devices Workshop

Screen Shot 2015-10-15 at 3.07.21 PM

Over the next few years, it is predicted that billions of devices will become increasingly interconnected and posses the ability to transfer data across networks without the need for human interaction. This environment of interconnectivity is known as the Internet of Things (IoT). In response to the emergence of this approach to product design, an unusual partnership between academia and industry has formed to prepare students to thrive in this new environment.  Nick Barendt and the LeanDog Studio have teamed up to offer a Connected Devices Workshop for Case Western Reserve University (CWRU) students during the Fall semester.  Students will get practical experience building a proof of concept system:  physical device, web integration, and mobile development.

Nick is a partner at LeanDog and an adjunct faculty member in the Department of Electrical Engineering and Computer Science at CWRU.  He helps lead the Design and Delivery Studio at LeanDog, building custom software products for clients.

Students will tackle hands-on assignments, learning to use the Unix command line shell, network communication, including Bluetooth Low Energy, embedded systems, cloud/web services, essential User Experience design, and native mobile development.

The course is unique in the breadth of material being covered – the goal being to provide students with a systems-level view of Connected Devices, gaining experience with each component in a complicated system.  Students are expected to leave the class with the ability to build their own proof-of-concept for a new product or service.  Additionally, students will develop enough experience and confidence to dive deeper into any of the technologies involved (e.g., web services, mobile development, etc.)

Given the ambitious syllabus, students will work in two-person teams, a practice known in the engineering and software development world as “pairing.”

“As Agile and Lean practitioners, we believe strongly in the value of pairing. Pairing with another student gives them the ability to share that journey with someone else who may have more experience in a technology area than they do. This allows the student to learn faster. Two heads are better than one when you are trying to solve a complicated problem,” said Nick Barendt, head of the Studio at Leandog.  

The broad spectrum of technologies covered in the class will be matched by the backgrounds of the students in attendance, whose areas of study range from computer science, to electrical engineering, to computer engineering. By working together in rotating pairs, students will learn to successfully collaborate with peers of different backgrounds and experience levels. This practice echos the same cross-functional team environments they will likely encounter in their professional careers.

Though Nick is the instructor of record for the course, he is pulling heavily on the depth and breadth of experience of the LeanDog Software Delivery and Design Studio to help provide this opportunity to students.  The LeanDog Studio has exceptional expertise in Agile/Lean design and development across Web, Mobile, Cloud, DevOps, and comprehensive User Experience.  Each lecture and assignment is being designed collaboratively with this cross-functional team.

About LeanDog

LeanDog is an Agile consulting, training and software design company that is redefining smart design and delivery, while helping to transform our clients’ organizations.

Agile Across Oceans

Last Wednesday, the Cleveland Council on World Affairs brought business development and entrepreneurial leaders from Cameroon, Gabon, Lesotho, Madagascar, Mauritius, Mozambique, Nigeria, and Sierra Leone to the LeanDog boat to see what we do. Nick Barendt, LeanDog’s Chief Development Officer, took the group on a tour of the office and studio, explaining how LeanDog makes use of Lean and Agile processes not only to build amazing software, but also run a dynamic, adaptable business in an environment that is constantly evolving and innovating.  While they were on board, they also got a lesson from Studio developer Gary on our how our 3D printer works, and the types of things we like to make with it. Katie Ferman, CCWA’s International Visitors Program Officer, remarked that “their visit to LeanDog was probably the single most interesting – and definitely the most visually engaging – session for our visitors during their time in Cleveland.”

tumblr_inline_nvg0asgdWQ1tc23o0_540tumblr_inline_nvg0b7cImN1tc23o0_540 tumblr_inline_nvg0arWtrA1tc23o0_540

Moving to the Boat

After nine months of waiting on boat renovations, the LeanDog team bid a fond farewell to the Hanger office, and said hello to the Kearsarge, one of Cleveland’s most recognizable landmarks.

The LeanDog team turned out in full-force on Halloweekend to unpack the office on the newly renovated boat, which is also home to advertising agency Arras Keathley.

Continue reading »