While we follow the 5 Day Design Sprint closely, we also iterate on the process. Earlier this year, we tried a few new things on prototyping day and, after some thoughtful iteration, we are delighted by something we uncovered — specifically, the evolution of the Stitcher role and the tools they need to succeed.

In the Design Sprint, it’s important that your entire Sprint team actively contribute towards the prototype. Typically, we assign many of the jobs identified in the original Sprint book, such as Maker, Writer, Asset Collector, and Interviewer. But, one role that we have seen evolve the most is the Stitcher, which is the person who typically brought all the assets together in InVision. But lately, we’ve seen this role grow, change, and utilize some handy tools that we’d like to share. Read on to find out what the Stitcher 2.0 looks like!

The Stitcher 2.0

In order for your makers to stay heads down on creating the prototype, we’ve found that it’s critical to have one person responsible for organizing and prioritizing all of the content and feedback.

In this way, our Stitcher is much like the “scrum master” for the prototype. They make sure that tasks are moving along (I describe our Kanban board below) and that all assets are organized in a way that is easy for the makers to pull into the prototype.

The Stitcher 2.0 is much like the “scrum master” for the prototype.

It is especially helpful if the Stitcher has access and is able to make edits to the prototype. This will ease the burden on the makers as the stitcher can drop edits in along the way.

PROTIP: While it may be tempting for the Stitcher to edit the copy as it is coming in, we discourage this and ask that s/he trust the team.

Kanban Boards are Essential

From the beginning, we have used a Kanban board during prototyping so that we have a visual overview of all tasks and who is responsible for each task. Usually, we have used a physical Kanban, made on the whiteboard. The Stitcher uses this tool to make sure everything is moving along and who to ask for an asset.

Kanban: a Japanese manufacturing system in which the supply of components is regulated through the use of an instruction card sent along the production line. From Japanese, Kanban is literally translated as sign board or visual signal.

From the very first time we introduced it, the Kanban was a big hit. It kept everyone engaged and they all loved pitching in and doing their part. As is often the case, this new innovation came with its own baggage. Now that we have numerous people creating and sharing copy, icons, images, video, stats, and data, the makers were getting overwhelmed by never-ending email threads. Not only was it a nightmare to scroll through, but it was also impossible to tell which version was authoritative.

Our Experiment with Google Docs

We experimented for a time with using Google Docs to allow the team to seamlessly collaborate and to have one source of truth for versioning.

Unfortunately, Google Docs proved to have two issues of its own: first, it compresses images, which makes them unusable for prototypes and second, many of our enterprise clients block Google Docs. We needed to find something different for organization.

Mural for the Win

We are now using Mural to organize our prototyping efforts, which works wonderfully. Not only does it support collaborating and sharing the copy (and uncompressed images!), we can easily build a Kanban board with virtual Post-its.

When the team is conformable with Mural we have them all join and drop their work into the workspace. Otherwise, the Stitcher will collect copy and assets via email or other team communication tools. Once in Mural, the Stitcher organizes the assets by screen to seamlessly integrate with the prototype. Typically, the Stitcher will do a few passes with the team to make sure everything is accurate in Mural and before spending the time to update the prototype.

Another fantastic thing about Mural is that is quickly becoming the tool of choice for enterprise UX teams and is an approved application so we don’t run into firewall or other security issues.

PROTIP: Name the cells of your storyboard with letters and numbers for better organization. We label our columns with numbers and our rows with letters. This allows us to refer to cells as A1, B4, C3, P0, etc. for tasks and asset organization to avoid confusion or long, unwieldy names.

The Stitcher & Playbacks

Also in the spirit of including everyone, we have regular readouts with the team during interview days. This helps to gather feedback along the way. The Stitcher also has a role here — he or she also collects feedback so that the maker(s) will have an organized and prioritized list of changes to the prototype.

Thanks for reading about how we’ve evolved the role of the Stitcher in Design Sprints. Please reach out if you have any questions or ideas to share!

The post We Can’t Live Without This Person During Prototyping appeared first on Voltage Control.

I was first introduced to Marcus when I read his post on medium titled: “Why Your Programmers Just Want to Code”. The article was quite popular. Like many folks, I was prepared to hate this article and one I started to read it, I realized Marcus had a played a trick on me. He went on to explain that even the most customer-focused engineers can’t do so in an environment that doesn’t reward or encourage the behavior.

I invited Marcus to speak at the first annual Austin CTO Summit. His talk was a simple note card based activity that he facilitated from the stage. The premise was for everyone to write down ideas for how to improve the summit and the suggestions would be judged based on seniority and or criteria specific to each individual. His simulation demonstrated that systems like this discourage many people from sharing thoughts and stifles innovation.

I’m excited to help bring Marcus to Austin on July 16th and 17th at Capital Factory where he and his wife will lead their Technical Leadership Workshop.

Great skills are not enough

You’re part of a solid team where everyone has great skills and are passionate about their craft. You use agile, or scrum, or Kanban. You have modern tools and frameworks. Everyone’s working hard, putting in the long hours.

“My team was good, but something was getting in the way of being it great.” — Workshop Attendee

The industry is filled with success stories about great software teams. Teams that deliver amazing things with very few people, under incredible pressures. Teams that collaborate, cover for each other, and focus on providing innovative products together. What are they doing differently?

Create an environment where everyone is fully engaged

Beyond Agile. Beyond Teams. Beyond Culture. Remember how excited you were when you heard about agile? The manifesto states that “The best architectures, requirements, and designs emerge from self-organizing teams.” The scrum framework adds to that idea by stating, “Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”

The Workshop

I’m bringing Marcus back to Austin for a 2-Day workshop focused on technical leaders. In the workshop, you will learn out to help your team perform at their best.

This is a hands-on workshop that will leave you with practical methods and solutions for improving how you and your team work together. The workshop is limited to 26 participants to guarantee an intimate and focused environment to maximize learning.

You’ll participate in engineering simulations which will challenge you and create “sticky” lessons that you’ll internalize and take back to your team.

Price: $2,099 per seat

Get Your Tickets Today

Who should attend?

• People who influence, organize, lead or manage smart technical people in order to achieve business goals.
• Tech Leads, Project Managers, CTO’s, QA Managers, Product Owners, Directors, Software Managers, ScrumMasters who want to improve leadership skills.
• Engineers, Programmers, Testers, and Architects who want to help their teams work better from the inside.

Day 1

[AM] Navigating Change and Learning

• Learn the difference between leading and managing
• Understand why change is hard, and how to help your team navigate it
• Uncover how to introduce self-forming project teams to your organization
• Use the Piaget learning cycle to build personal and team improvements
• Connect hands-on design exercises to real-world situations

“The debrief following each exercise provided ample opportunity for deep thinking about how we approach team dynamics, leadership, communication, etc. within our organizations.” — Workshop Attendee

[PM] Building A Productive Team Environment

• Learn the MOI(J) model of leadership
• Put your team’s ideas into practice in the real-world
• Hone your observation and feedback skills
• Improve your retrospective and structured debriefing skills

“The program revealed traits I want to avoid as a leader.” — Workshop Attendee

Day 2

[AM] Improve Communication about Requirements and Design

• Observe the impact of time pressure on technical communications
• Improve communication about complex technical tasks
• Understand the cost of assimilating new members into a team
• Identify real-world areas of improvement for your team’s communication practice

“I gained insight into what might demotivate people.” — Workshop Attendee

[PM] Removing Silos and Low-Bandwidth Communication

• Improve communication with remote engineers
• Understand the role of conversation in communication
• Observe the effects of silos on team motivation
• Observe the effects of Management by Walking Around
• Build proficiency in leading through asking, rather than telling

“Seeing the Satir change curve really helped me recognize that the feelings I had against change were something that affected everyone, even if there is a little difference between each of our experiences.” — Workshop Attendee

Space is Precious

This unique, hands-on workshop is held in small venues where the facilitators constantly interact alongside participants during the workshop.

Each workshop is limited to only 26 participants to ensure everyone has the best experience possible. These workshops fill up fast, so register today.

“You Gotta Love It” Guarantee

All of Marcus’ workshops offer a “You Gotta Love It” 100% money back guarantee. If you attend and feel the workshop was a waste of your money and time, they will issue a full refund, no questions asked. If you’re not happy, we don’t get paid. It’s as simple as that.

“I continue to work one-on-one with Marcus to this day, and I hope I will always be able to lean on him and dialog about challenges He is worth way more than you can ever pay him.” — Andrew Coven, Senior Director of Platform Engineering, Box.com

About the Facilitators

Their goal is to revolutionize the world of work for engineers and those who lead them. They believe that every engineer deserves a good boss, and that any engineer can become one. They stand apart from those who preach that “Leaders are born, not made”, proudly helping great coders become great leaders.

When you sign-up you they meet them, Marcus and Amy. They aren’t a large corporate team with an army of drone trainers. They’re a small, Oregon based team who does 100% of the training ourselves. They create and test their own curriculum. They live and breathe this stuff, and it shows.

Marcus Blankenship

Marcus has worked as a Software Engineer, Architect, Team Lead, Software Manager, Consultancy Owner, College Instructor, Leadership Coach and Business Coach. He specializes in helping Technical Managers and Leaders create high-performing organizations.

His book, Habits That Ruin Your Technical Team is now available. He is currently pursuing an I/O Psychology Degree (Leadership Specialization) from Penn State and lives in Eastern Oregon.

Amy Blankenship, RN, BSN, MSN-Ed

Amy has worked as a Nursing Instructor at Oregon Health Sciences University, specializing in clinical simulations and interprofessional instruction. She has also worked as a post-surgical nurse, hospice nurse, and a hospice clinical manager.

She currently serves as an Executive Board Member of Klamath Hospice, on the Oregon State Board of Nursing Curriculum Council, and as a leadership mentor for the Oregon Nurses Association. She will enter a Ph.D. program in 2018 and also lives in Eastern Oregon.

The post Technical Leadership Workshop, July 16/17 appeared first on Voltage Control.

A common source of confusion around Design Sprints relates to the popularity of Agile development practices, specifically Scrum. When most people hear the word “sprint,” they think of the cell phone company, Scrum rituals, or “that stuff our dev team does.” Because of this, there have been several articles discussing the merits of Design Sprints versus Agile Sprints. One even suggested that Design Sprints may be a way to avoid the purgatory of Agile Sprints.

I’m here to argue that they can be harmonious, not antagonistic. Design Sprints and Agile Sprints work well together and even complement each other. Below are my thoughts on how using Design Sprints in front of an Agile development process can actually lead to better results.

Quick Intro to Agile & Scrum

First, I’d like to cover a few basics of Agile software development for those who are new to it. Agile first came onto the scene with the Agile manifesto, written in 2001. The manifesto consists of 4 values and 12 principles. I’ve listed the values here because I believe in them whole-heartedly.

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

“Agile Sprints” are part of a specific Agile development process called Scrum.

Scrum is an agile framework for managing work with an emphasis on software development. It is designed for teams of three to nine developers who break their work into actions that can be completed within time-boxed iterations, called Sprints (30 days or less) and track progress and re-plan in 15-minute stand-up meetings, called Daily Scrums. — Wikipedia

Agile Versus Sprints

Agile and Scrum are ways in which you build software. They define tools, practices, and rituals for conducting daily engineering tasks. A Design Sprint is a tool you use to dive deep into a problem, to understand if you should build something, and determine what exactly you should build. As you can see, Agile Sprints and Design Sprints share a few core principles in common. They both encourage cross-functional teams, seek to move quickly, and continually react to new information.

When Agile first emerged, organizations began to sit cross-functional team members close to each other so that they could become aware of issues more quickly. Unfortunately, designers were not always part of these teams. Often, the UX researchers and visual designers were part of another team or in an outside agency and their working style closely resembled waterfall development.

While Scrum defines a great methodology for how we should build our software, Design Sprints are a perfect method for determining what we should build.

Working in Sync

While Scrum defines a great methodology for how we should build our software, Design Sprints are a perfect method for determining what we should build. In Scrum, there is a Sprint backlog, which is fed by a product backlog. Design Sprints can help teams focus their product backlog and align the entire team on the features and projects with the highest business potential. They are also an effective tool for validating user requirements that are teed up in the Sprint backlog. In Design Sprints, you often iterate and test much like you would in Scrum; however, Sprints do this iteration through quick designs and light-weight prototypes, which are much less expensive and carry lower risk.

You Need Both

I’m sure you are familiar with the expression “garbage in, garbage out.” Scrum is a great process for developing code quickly, keeping projects moving, and adapting to new requirements. However, if you are building the wrong thing, it simply means you’ll have the wrong thing faster than with waterfall.

If you are building the wrong thing, it simply means you’ll have the wrong thing faster than with waterfall.

Some will argue that Scrum’s iterative nature will allow you to discover these issues and adjust course and that Design Sprints aren’t necessary. There are a couple of issues with this line of thinking:

1. If your focus is on pushing code and building features, it will take you a long time to discover the cracks in your foundation.
2. Once you have built the system, the sunk cost fallacy may make you inclined to continue investing in the project long after you realize it’s not a winner.
3. Technical debt is a measure of uncertainty, so the more you build from a point of ignorance, the more technical debt you accumulate.
4. Design Sprints leave you with a prototype that becomes a “visual spec,” which can help to decorate and improve on the Agile acceptance criteria.

Prototypes Set You Up for Success

I think starting your Agile process with a focused Design Sprint sets you up for much greater success down the road. That’s because Sprints are predicated on quick user feedback from rapid prototyping. Prototypes are by nature disposable and can be easily updated without fear of technical debt or other hidden costs down the road. They allow you to test ideas and features quickly and increase your level of confidence prior to sending the project through an Agile Sprint. When you are done with a Design Sprint, you are ready to build.

When you are done with a Design Sprint, you are ready to build.

You’ll leave your Design Sprint with a functioning prototype that has been battle tested with users. This prototype becomes the “visual spec,” which helps improve on the Agile acceptance criteria. There will be less time needed to write the acceptance criteria because your visual prototype is highly specific, leading to much less ambiguity.

I encourage all Scrum teams to think about their Scrum cadence and on what frequency it makes sense for them to conduct a Design Sprint first. In fact, I’m noticing more and more companies using Design Sprints as a way to validate product requirements and align stakeholders prior to sending their project through an Agile development process.

I would love to hear your thoughts on how you use Design Sprints and the Agile process to inform each other. What’s your cadence?

The post Friends, Not Enemies appeared first on Voltage Control.