Freenode Infra-Talk Channel

Related Stories

• HTML5 Date Inputs and Ember.js
• Build a Rich JavaScript Front End with Grunt
• Dynamic Binding in Ember.js Using Observers

On the weekend of March 22-23, a group of educators, their students, and industry professionals came together at Calvin College’s Prince Center for the Michigan Celebration of Women in Computing or MICWIC. Along with my colleague Carl Erickson, I had the privilege of attending this event and getting to know some of the best and brightest new minds studying computing in the state of Michigan.

Friday evening conference attendees enjoyed a delicious dinner, a keynote address from Rane Johnson of Microsoft Research, and an award ceremony honoring the Michigan recipients of the NCWIT Aspirations Award, a prize for high school young women who are interested in pursuing computer science as their career field.

On Saturday, conference activities continued with lightning talks, panels, paper sessions, and a career fair. Along with Danielle Pretzer (Steelcase), Rajani Sinha (Chrysler), and Gretal Miller (Michigan State University) I spoke on a panel titled “Software Teams in Industry.” We discussed and contrasted how our teams operate at our respective companies, shared perspective on how to effectively collaborate with team members, and answered questions about how students could be more prepared to work in the field. For me, it was fun share with students AO’s balanced teams approach and share how we’ve successfully integrated design and development to build better software. I feel that Gretal, Rajani, Danielle, and I were able to help students more clearly envision what their career might look like in a variety of settings — small companies, large companies, and education.

As a silver sponsor of the conference, AO had a table at the career fair. Carl and I had the opportunity to meet many bright young people and have some great discussions about careers in software. It was great to see the enthusiasm and verve of the conference participants.

MICWIC was a fabulous event, and Atomic Object was proud to be a part of it. I’d like to say a public thank-you to the conference organizers, who worked hard (for free!) to make it a great experience for all attendees. I look forward to attending the next MICWIC conference in 2015.

The post Atomic Object at the Michigan Celebration of Women in Computing appeared first on Atomic Spin.

Related Stories

• Sustainability at Atomic Object
• Atomic Presentations at GRDevDay 2013
• Connecting with the Future of Our Industry

In a previous post, Tear Down the Walls! — Shattering Team Boundaries, I discussed the boundaries (or silos) that traditional teams often end up segregating into, especially when deadlines are looming.

The project I am on has many teams scattered across multiple physical locations (even continents), and teams are frequently under separate silos of management. Epic-level stories that cross these geographical and management boundaries are a bear to coordinate in the context of traditional/static teams.

One strategy that we have been using to break down boundaries is lending resources to other teams. This has helped the problem in some cases, although management of priorities and dependencies across team boundaries requires a high level of coordination and compromise, especially when key milestones are approaching. Local team needs too frequently get prioritized over efforts that cross team boundaries, even though they may have critical importance to the product being developed.

In this post, I propose a solution to this “people problem” that involves dynamically forming teams around epics. In order for this to work, buy-in from developers and (more importantly) the managers and home-team leads that own these resources is crucial.

Acknowledging the REAL Problem

Assaf Stone authored an excellent post, 10 Signs that Your Team Isn’t Really Agile, that I have been referring back to regularly to keep myself in check and to validate our own strategies against these guidelines. At the top of the list is one that has bothered me, because although it makes sense, our teams keep violating it time and time again.

You might not be truly agile if…

1. Your team is not responsible for the entire story - Perhaps the most important aspect of an agile team is that it is cross functional. This means that the team, as a whole, have all the skills required to deliver a valuable product increment. If a team has only client developers, then all server-side tasks are probably relegated to a different team. In this case, the team is not handling a story from end to end; when they complete their work, no value has been added to the product – not in the eyes of the customer! Teams that work like this resemble a factory where the product sits on the conveyor belt and different layers are added to it by different teams. At no moment till the last team does its thing is the feature (or product) done.

Having all the necessary skills and expertise to conquer a user story (or especially an epic) is indeed the ideal way to conquer a largely scoped story, but this is not a realistic expectation in a large organization with many diverse and/or distributed teams.

The Situation at Hand

A large epic story we have been working on, across many teams, has presented large problems for integration and measurable progress. A major pitfall we hit recently (and are still trying to recover from) happened because team A had piece X, and team B had piece Y. There were corresponding, yet separate, stories defined on each side of the fence for teams A and B. Team A “completed” their part of the story according to the requirements laid forth, and then the switch was flippped to roll these changes into the default working branch of the repository.

Unfortunately, team B, which consisted of… well… just me for this epic. When “the switch” was flipped, my half for this functionality was partially incomplete, and there were integration issues that brought down “the build” for a few days during a really critical time in the project where we were trying to deliver our first pre-production release.

Since then, we have been struggling, monkey-patching, and working way too many hours. And as a result, we are still in this dilemma and have built up significant technical debt in the meantime.

This problem would likely never have happened if we were all on the same team.

On our project, every team has their own team leads, scrum masters, and/or managers. Unfortunately, this usually leads to developers being being statically allocated and too frequently over/under-utilized.

When it comes time to meeting commitments at critical project junctures, and the deliverable is at risk, pressure from the upper levels increases. As this trend continues, week after week, developers tire and tend to claim their stories complete haphazardly, in order to show progress. As a result, defect rates increase, which leads to finger-pointing, more meetings… and frustration across the board.

Refactoring the Team

In order to eliminate this distorted concept of done-ness, a team-spanning epic is better tackled if all people needed to complete the epic were reorganized into a new team. This new team would have all domain representatives and do-ers, from the various teams, reintegrated into a force more able to conquer the challenge at hand. The team shares a formal backlog, user stories are refined, executed, and accepted… together.

Much thanks to Assaf Stone for making me fuss with this dilemma of common ownership, and the arriving at the same conclusion. Hopefully utilizing dynamically-formed teams can help my team — others reading this post — overcome this common hurdle of integration.

How does your organization deal with epic stories, or even user stories that cross and/or threaten team boundaries?

The post Tear Down the Walls! (part deux): Reorganizing Teams Around Epics appeared first on Atomic Spin.

Related Stories

• Agile XP Meets Critical Chain – Part 1: Getting Faster Delivery
• 5 Techniques to Get the Most Out of Your Software Team
• Defining “In Progress”

Tmux is a powerful terminal multiplexer, and its built-in support for scripting allows you to create new features according to your own workflow.

I spend most of my day in Tmux, at the command line, grepping through codebases and editing files with Vim. I copied and pasted or re-typed file names for a long time before I realized how irritated I was that I couldn’t merely click on a file name and immediately open that file to the given line.

An IDE would have that functionality, and being firmly in the camp of command line as IDE, I set out to right this wrong.

Some Background

Most of the time I use grep with the -n option, which includes the line number of all matches.

$ grep -n "question" *
./config.rb:42:    question = 6 * 9

To enter Tmux’s copy mode, hit your prefix key combination (mine is Ctrl-b) then the [ key. Cursor movement within copy mode depends on whether you have Tmux set to Vi or Emacs key bindings. I use Vi key bindings below. If you'd like to use Emacs key bindings instead, this Superuser answer has a helpful conversion table.

1. Figure Out the Keystrokes

The first step to scripting our new feature is to figure out how to do it manually. In copy mode, navigate to the line of the file you want to open. We need to grab the filename and line number from grep's output. The colons around the line number serve as convenient landmarks. Here are the steps we need to automate:

1. Move the cursor to the beginning of the line.
2. Start selecting text.
3. Move the cursor to the first colon.
4. Move the cursor to the character before the second colon.
5. Copy the selected text.

To accomplish this with Vi key bindings, press ^ to jump to the beginning of the line, then press spacebar to start selecting text. Skip to the next colon by pressing f then :. Skip to the character before the next colon by pressing t then :. To copy the selected text to Tmux's buffer, hit the enter key.

2. Bind the Keystrokes to a Keyboard Shortcut

We're not yet ready to complete our feature, but it's a good time to document what we've learned. Let's trigger these keystrokes with a Tmux key binding. Open your .tmux.conf file and choose a key to use. We can register the keyboard shortcut with Tmux using the bind command. I've picked g, meaning Tmux will execute the given command when I press my prefix key combination (Ctrl-b) followed by the g key.

bind g send "0 f:t:" C-m

Tmux's send command replays keystrokes, in this case the series of characters we used to copy the filename and line number. The C-m at the end is interpreted by Tmux as the enter key.

Save the config, and load up a Tmux session to test it. Run a grep command with the -n option, then enter copy mode and move the cursor to a line with a file you want to open. When you hit your prefix key combination followed by the g key, you'll find Tmux has dropped out of copy mode and returned you to the command line. To make sure it also copied the filename and line number, run the command tmux save-buffer -. This command will print out the contents of Tmux's copy buffer, in this case the selection copied by your new key binding.

3. Create a Helper Script

At this point we have the filename and line number as output by grep, with a colon separating the two parts. If your preferred editor won't accept that format, you'll need a helper script. Vim accepts a line number separate from the filename and prefixed by a + sign, so here's a script that splits our copied contents at the colon and passes them to Vim:

#!/bin/bash
 
filename=$(echo "$1" | cut -d':' -f1)
lineNumber=$(echo "$1" | cut -d':' -f2)
vim $filename +$lineNumber

Save this script somewhere on your path so you can invoke it anywhere. While I originally named this script vim-from-grepped, I've found it useful enough to shorten the name to vimfg.

4. Update the Key Binding We Created Earlier

You can test the script by typing vimfg and hitting your prefix key combination followed by ], which will paste the contents of Tmux’s copy buffer. Hit enter and see if the script does what you want. If so, we’re ready to automate this step in our key binding. We’ll add the name of our script to the initial send command, paste the contents of Tmux’s copy buffer using Tmux’s paste-buffer command, and hit enter to invoke the script.

bind g send "0 f:t:" C-m "vimfg " \; paste-buffer \; send C-m

Because a semicolon would signify the end of the bind command, we have to escape both semicolons with backslashes.

With all of these pieces in place you can spin up Tmux, run grep -rn "<pattern>" ., enter copy mode, move the cursor to the file you want to open, and hit your prefix key combination followed by the g key. You should then be in Vim on the line number grep found matching your pattern.

Scripting Tmux is a very powerful addition to your command line toolset. If you have other tips for augmenting Tmux, I’d love to hear about them!

The post An Introduction to Scripting Tmux Key Bindings appeared first on Atomic Spin.

Related Stories

• Linux Encryption in the Cloud using LUKS on Linode
• Real-time Generation of Numeric Data Fixtures in IronPython
• Red Green Performance Testing with The Grinder

“…no one is born a great cook, one learns by doing.”
– Julia Child, My Life in France

Or, to paraphrase the late great Julia — no one is born a great designer, one learns by doing (and testing). Cooks test out their recipes with an audience, and the same principle applies to new products and services. Usability testing is necessary to prove the product viability, alongside making sure that the proposed design will meet (and exceed) the user’s expectations.

Think of usability testing as the test kitchen for successful software design. You put together some great ingredients, follow the necessary steps carefully, and – voila! – a greater design emerges.

Your list of ingredients could range from artifacts (paper or digital) to principles regarding design strategy that you want to keep in mind along the way. As with, say, a bread recipe, the steps will vary project by project, but the general format is something that can be carried through all of your testing adventures and continually refined.

Validation: Putting Your Ingredients to Work

Define goals up front on what needs to be tested — what do you want to come out of the interviews knowing more about? This knowledge should be substantial enough to equip you to make decisions about how and where to iterate the design. When revisiting your initial objectives, you should feel confident you know how to address each issue.

When constructing…

• Think about the environment of your end user. What is the product experience going to feel like? Simulate your testing environment and tailor your artifacts to the end product as closely as possible.
• Vary the user profile (analytical vs. creative). Sprinkle in a few power users to each engagement. They are your forward-thinkers, and can provide unpredictable usage patterns.
• Find your go-to person on the inside — someone who is familiar with various users, departments, and settings. You need this person to schedule your interviews and provide some important up-front product information to prep users ahead of time.

When conducting…

• Whenever possible, test in the environment of your end user. Eliminate any need for human intervention, which threatens the purity of your test results.
• Use your test plan as your guide. It should act as your script, providing a consistent template for each interview. It’s important to stay on track with your original plan, but also necessary to maintain some flexibility for elements of surprise.
• Note every aspect of the user’s behavior. Are users interacting with things in the room, drawing on a whiteboard, adjusting lighting, closing doors? Are patterns beginning to emerge as the day goes on?
• When taking notes, quote your user verbatim, if that is the best way to describe their reaction. How successfully you relay information back to internal teams will be critical in spreading the valuable insights from usability testing.
• If only for a couple of sessions, get your client to sit in. Their participation will be critical to the success of the project. As an observer, they can absorb information without having to engage with the user — although being able to chime in with questions is another key benefit. If necessary, capture video of the engagement to share with remote team members.

When consolidating…

• Assemble your artifacts and present your data in a format that is tailored to your client’s needs. It should be easily consumable and reveal in one glance the most important discoveries found in testing.
• Be sure to classify issues related to utility vs. usability (see below). Avoid getting into design details that can be sorted out later. Just agree on the top issues, recommendations, and tactical areas in the design that need to be addressed.
• Ask your client to review these issues with their peers. Do they experience this issue too? Have they heard users reporting it? Are there any developed work-arounds created to address this problem? Peers will provide valuable input, especially if they’re in touch with end users.

Closing Thoughts

New insights gained through testing will inform how you enhance your recipe (or design). Maintaining consensus not only keeps the confidence building and relationships growing stronger, it also creates a platform for more well-informed (smarter) decisions. More minds are greater than one, and having more minds witnessing the user reactions with the design will provide everyone context as to why decisions were made along the way.

Don’t assume what the users may need help with when interacting with your product. The interface should be a guide to get them to their destination with little assumption made in advance. For information on why usability testing matters, read my latest post, Why Usability Testing Matters: A Newbie’s Perspective.

In the meantime, happy cooking!

* Iteration Cycle
** 6 UCD Principles

The post Test(ing) Kitchen: Assembling the Ingredients for Your Next Usability Test appeared first on Atomic Spin.

Related Stories

• Why Usability Testing Matters: A Newbie’s Perspective
• Rethinking Online Mass Registration
• Stacks, Crumbs, and Keynote: iOS Interface Ideas

On March 27, 2013 Local First held its 5th Annual Sustainable Business Conference. I was invited to speak on a panel about sustainability initiatives in business. My fellow panelists were Marcia Rapp of the Grand Rapids Community Foundation, Kris Spaulding of Brewery Vivant, and Matt VanSweden of Integrated Architecture. Bill Smith of CompuCraft was our panel’s moderator.

Participating on this panel gave me the chance to share some of the aspects of sustainability that are important to Atomic Object. I gave the audience a sense of Atomic’s strong culture and the sustainable business practices we have adopted since we opened our doors in 2001.

I won’t claim that we’ve flawlessly executed on all of our many sustainable business efforts, but experimentation and improvement trump perfection. And pragmatic beats dogmatic in our complex and dynamic business environment.

Workplace and Community Sustainability

Buildings and Operations

We invested in and renovated an existing historic building in Grand Rapids and leased and renovated one floor of an old building in downtown Detroit. In both cases we:

• Renovated for energy efficiency – insulation, HVAC and high efficiency lighting.
• Used responsible materials in the renovations.
• Participate in Consumers Energy’s Green Generation program.

On a daily basis we:

• Recycle plastic, metal, glass, paper, cardboard, electronics, batteries etc.
• Compost our food waste.
• Purchase and use lower-impact cleaning products and office supplies.
• Serve fresh, healthy snacks.
• Use real dishware and glassware vs one-time use products.

Non-Car Commuting

Almost 30% of our Grand Rapids employees either bike, walk, or take the bus to work most days of the week. Cyclists are the strongest contingent of our non-car commuters, so Atomic has evolved to be a decidedly bike-friendly workplace. To support our employees who bike commute to work, we provide:

• Indoor and outdoor bike parking.
• A shower so cyclists can clean up.
• A bike helmet for anyone who regularly commutes by bike.
• A bike commuter reimbursement to help with maintenance and repairs.
• A company car to help bus, bike, and walking commuters travel to off-site meetings, etc.

Local Business Support

• We frequent our neighborhood’s many restaurants, coffee shops, and bars.
• We spend locally on supplies and professional services.
• We cater meals from restaurants within walking distance.
• We provision our office snacks from the Fulton Street Farmers Market, in season.
• We support and admire the beauty of the urban farm right across the street.

Business Sustainability

Profit Sharing

Sustainable companies have high levels of engagement with their employees because, in part,  they share success with everybody. Atomic Object shares 25% of its profits with its employees. Our profits are shared quarterly via cash bonuses and annually via 401k profit sharing contributions.

Employee Ownership

Early in 2013, we instituted an employee stock purchase plan to further broaden ownership in Atomic Object. We’ve always been 100% employee owned, and our goal is to be very broadly 100% employee owned in the future. We believe this approach to ownership will only strengthen and sustain Atomic Object for a long time.

Read more about Atomic’s adventures in ownership on Carl’s blog.

Sustainable Pace

We practice sustainable pace — responsible working hours that promote balance and quality work outcomes. Over-allocated, stressed out people can’t offer up their best work. A business model built on the assumption of an unsustainable work pace would jeopardize our ability to keep the best and brightest people who hit deadlines and deliver high quality results to our customers.

Read more about how research on productivity supports sustainable pace as a practice.

Women in Software

The software profession depends on the sustained availability of talented and skilled designers and developers. Atomic acknowledges there is an acute shortage of women in the tech industry, and we want to invest in efforts to increase the number of women who consider and pursue computer science related careers.

We contribute to the strength of the community of women who are software designers and developers by supporting women-focused tech conferences like Michigan Celebration of Women in Computing and groups like Girl Develop It, as well as hiring Computer Science students as summer interns.

We also offer BitCamp, a one-day intro to software development focused on middle-school aged girls, to get them interested in computer science.

Shared Values

Last, but never least, our shared values sustain us, not just as a company, but as friends and family. Our values guide us as we filter the opportunities and challenges of doing business every day, and as we plan strategically into the future. These are the five value mantras that define our culture.

What business sustainability practices have you tried in your business?

What worked? What didn’t?

The post Sustainability at Atomic Object appeared first on Atomic Spin.

Related Stories

• Atomic Object Gets a 3D Printer
• Cross-pollinating Innovation Across the Organization
• If Time Is our Most Valuable Resource, Trust Is our Second

I believe frameworks that foster cross-pollination of ideas work better than top-down policy implementation when it comes to spreading knowledge and innovation across an organization.

The Need to Share Knowledge and Innovation

Atomic consists of self-managing teams that are organized around projects. Our projects can typically last anywhere from three months to over two years, and people often get shifted around when projects end and new projects start.

Atomic applies user-centered design and agile practices through our integrated teams of designers and developers. Our teams follow heuristics and a general product development process, but they also have the autonomy and authority to innovate and try new things.

The long cycle time of projects means that innovation within teams can stay localized for significant periods of time. Theoretically, it could take several years for certain practices to spread throughout the office. I wanted to speed up the sharing of knowledge and innovation across the company.

There’s always the command and control, top-down approach of identifying the best practices, distilling them into an algorithmic process, and educating everyone on the new process, but I agree with Joel Spolsky that command and control management doesn’t work in places like Atomic.

Atomic’s Design Series

I thought it would be more interesting and effective to create a framework that allowed for bottom-up sharing and cross-pollination of knowledge. I created the Atomic Design Series that consisted of six months of presentations and workshops. There was approximately one presentation and one workshop each month.

When I first created the series, I had no idea what content would be included or if anyone would attend. I asked for volunteers to present on subjects of interest. I believed the framework was enough to inspire people to Teach and Learn.

I couldn’t have asked for better engagement. The series filled up quickly with presenters. Each event was interesting, well attended, and generated great discussion.

Presentations were held at lunch, and Atomic provided food and refreshments. Presenters spoke for half an hour, and we had fishbowl discussion or open Q&A for the following half hour.

Kedron Presenting

Workshops happened on Fridays at 4pm. Atomic provided snacks and catered in beer and wine (thanks Aprille from “D. Schulers“). Presenters put on interactive workshops that lasted approximately two hours.

Paul Presenting

The events were held at our Grand Rapids office. Out of 37 full-time Atoms in Grand Rapids, we had an average of 22 people attend each event. The attendance min and max were 18 and 30. People attended during their free time out of interest for professional development.

Chris Listening to Presentation

We spent a total of 127 hours creating and giving the presentations as well as managing the framework. Total attendee hours came to 348 hours. My time involvement came to 11 hours including time spent contributing to one of the presentations.

Brittany and Matt at a Workshop

The design series framework offered simple opportunities and constraints. The participants made the series great. The series reinforced the benefits of creating enabling frameworks instead of creating policy and process.

Please share any methods you are using to promote cross-pollination of innovation and knowledge between teams in your organization.

Design Series Events

Below is a summary of the events we held in our series. Please feel free to contact us if you are interested in having us speak at your company.

Presentation: What is design? – Kedron Rhodes
A foundational overview of design. What do I think of when I say design? What do you think of? There are a lot of definitions. Let’s focus on one definition of design: finding the intersection of the problem, the people, and the constraints.

Presentation: Visualization is for everyone – Matt Fletcher
“Visualization is for everyone.” Duh. Right? Duh? Err…maybe not. Until earlier this year I wouldn’t say visualization is for me. Visualization was always one of the last tools I would reach for. Now that I have a better understanding of what visualization is (read: not simply pretty pictures), I’d like to share the tools and tactics that turned this word-oriented persona into one of visualization’s biggest advocates.

Presentation: Using Storyboards and Interface Sketches to drive backlog creation and build team consensus – Brittany Hunter
This will be a case study of a project’s usage of storyboard and interface sketches. We’ll talk about what we did, why we did it, what the benefits and drawbacks were to our techniques.

Presentation: Data Visualization – Karlin Fox
Principles for communicating data visually to customers, users, or fellow makers. Covering guidelines by Alberto Cairo, Edward Tufte and Stephen Few, and examples by Nicholas Felton and David McCandless.

Presentation: Visual Storytelling Lessons from Understanding Comics – Jason Porritt
How do you tell a story using still, silent frames on a page? Comic books have a lot in common with the storyboards we create. We’ll talk about the spectrum of iconic to objectified images, types of frame-to-frame transitions, time, motion, mood, and how we can apply them to communicate effectively.

Presentation: The Design of Business, Roger Martin – Carl Erickson
The knowledge funnel describes the tension between exploration of new knowledge and exploitation of existing knowledge. I found it to be a simple and powerful model, and one which is useful to understand for both Atomic’s business and our projects.

Workshop: The Whats of design thinking – Matt Fletcher
Design thinking is an approach to growing a business. You could pour over market analysis Excel spreadsheets — but then you’d be building boring solutions that no one cares about. Join me as we empathize with people and use design thinking to work through what is, what if, what wows, and what works to discover new product and service offerings.

Workshop: Visualization techniques and exercises – Matt Fletcher
“To solve the problems of today, we need to see and hear, read and look, write and draw.” – Dan Roam, Blah Blah Blah

Dan Roam describes pictures and words as the two wheels of a bicycle. Sure, you could ride a unicycle (by communicating only in words), but you’ll get a lot further on the bicycle. Join me as we review some of Dan’s techniques for creating and refining pictures to communicate complex ideas.

Workshop: All I Need to know about Design, I learned in Middle-School Art Class – Brittany Hunter
Heavyweight tools such as OmniGraffle and Photoshop make it difficult to iterate on project artifacts such as storyboards and wireframes. Often, all you need to gain team consensus on scenarios and features are a few quick sketches. In this workshop, we’ll play with pencils, paper, pens, tape, tracing paper, printouts, photocopies, scissors, rulers, and other fun tools to learn techniques that anybody can use to quickly sketch out a storyboard or interface.

Workshop: Cooper UX bootcamp review – Paul Hart
One of the most helpful things I took away from the Cooper UX Bootcamp is to take a step back before I begin the process of deciding the ins and outs of the app and think about the big picture. By understanding the context, motivations and desires of the person using the product, I can better determine how to design the details.

This part of the design process involves telling stories about the future to enhance the user’s experience. From these stories, key activities are identified where the needs and desires of the user intersect with the business goals. And, finally, the graphic user interface can be brought to life. The level of fidelity goes up with each step.

Workshop: Innovation Games – Mike Marsiglia
Atomic Object has used Luke Hohmann’s Innovation Games® many times during the Research, Design, and Planning phase of our projects. Atomic takes a slightly different approach than Luke recommends. Mike will present how Atomic applies Innovation Games to our work and will specifically focus on the Product Box game.

The post Cross-pollinating Innovation Across the Organization appeared first on Atomic Spin.

Related Stories

• If Time Is our Most Valuable Resource, Trust Is our Second
• A Walk Along the Detroit Riverfront
• Atomic Object Gets a 3D Printer