Purity vs. Pragmatism

 

religion“That’s not Agile!”

 

“We’re not being lean enough.”

 

“We’re not supposed to make deliverables!”

 

Sound familiar? I hear these statements all the time from teams moving towards a more evidence-based approach to product discovery, conception and production. Somewhere, someone made a decision for the teams to now “do Agile & Lean” and so, books were bought, conferences attended and index cards purchased. The teams set off with a healthy mix of trepidation and optimism and began practicing the newly learned processes – visions of stand-ups, post-it notes, IPM’s and validated learning in their heads.

 

Except it’s never that clean.

 

Something gets in the way – reality. Reality consists of:

 

  • The client (or stakeholder) who doesn’t really understand what being agile actually means demanding roadmaps, and sitemaps, and journey maps and story maps.
  • The project budget, which is allocated not just for discovery but also for actual production of a software application.
  • Distributed teams who struggle to maintain transparency and real-time conversation.
  • Experiment results that don’t give a clear indication of next steps.
  • Technological constraints that won’t allow production-level scaling of the optimal solution.
  • A corporate culture that frowns on failure and makes collaboration difficult

 

And so much more…

 

What is the newly minted Agile/Lean team to do when faced with these harsh realities?

 

Do you push through, sticking only to the fundamentals in the books and tutorials hoping things will work out? Or do you take the pragmatic approach and adjust as needed to accommodate the realities on the ground?

 

The answer, of course, is the pragmatic route. Each project, team, product, company, industry and market brings with it its own context. These contexts demand a unique approach that can’t be predicted in a book or manifesto. The frameworks articulated in those books are starting points. Once they get wrapped in these contexts they will inevitably morph.

 

And that’s OK.

 

Ultimately, what you really need is to ship product. Lean and Agile will help you gather evidence, determine more successful paths, produce working software faster and build a shared understanding between your teammates, clients and stakeholders. Start with these philosophies. Use them to build evidence, insight, direction, learning and value. But keep this in mind – there is no scale for agility or lean-ness. There is no such thing as not being “lean enough” or “agile enough.”

 

 

 

 

Posted in agile, design, enterprise, lean startup, Lean UX, Research, startups, work ethic | 1 Comment

7 things I learned at Lean Day: West

The attendees of Lean Day: West

The attendees of Lean Day: West

Earlier this week we put on Lean Day: West in Portland, OR. The goal of the conference was to bring together practitioners of lean, agile, lean startup and lean ux from the enterprise and share their stories of success, failure and most importantly learning. Our hope was that every attendee would take away at least one tip, tactic, technique or method they could apply as soon as they got back to the office.

We had an amazing lineup of speakers including Greg Petroff from GE, Farrah Bostic from The Difference Engine, Lionel Mohri from Intuit, Bill Scott from Paypal, Emily Holmes from Hobsons, Jeff Hutkoff from The Weather Channel, Aaron Sanders from Co-Makers, Ben Burton from Corespring and Jono Mallanyk from Neo. Each presentation brought a different perspective on how to improve the product development process by focusing on the customer, objective outcomes and doing only what is necessary to move forward — all while navigating complex organizational hierarchies.

I learned a lot over the 2 and a half days and have summed up those learnings in the following seven thoughts:

  1. Lean can scale – if you needed any further proof that cross-functional agility and an organization-wide commitment to empowerment, waste reduction and great user experience can be achieved in a large organization, Greg Petroff from GE laid those doubts to rest. GE’s industrial internet design system empowers both GE’s designers AND their developers to prototype, prove out and create beautiful software tools.
  2. Lean crosses industries – on stage at Lean Day: West we had speakers from large manufacturing, media, education and financial services. All of them found ways to apply these ideas to their company and their audience.
  3. Perception of “roles” has to change – every success story shared at the conference focused on building cross-functional teams that respected *all* the skills each team  member brought to the group. The most successful teams didn’t focus on job titles or roles and didn’t limit each others’ contributions simply because it was “not in their job description.”
  4. Empower everyone – if there’s something a team member needs to do in order to move forward, provide them with the tools and the know-how to get that work done instead of making them dependent on other team members. This was a recurring theme.
  5. Be objective – each case study we heard centered on objective decision making based on pre-defined goals. These objectives were shared and bought in to by the teams so that when tough decisions needed to be made, they went much more smoothly.
  6. Don’t be afraid to throw things away – what’s worse – throwing away a half-built product you’ve proven won’t work for your audience or finishing and shipping it simply because you’ve come halfway? Throw it away – no matter how much you love it or how much has been sunk into it. If you’ve disproven something, be ruthless and dump it.
  7. Cultures have to shift – all of these ideals point to shifting cultures – even in big companies. Cultures will need to adjust to be more forgiving and promote experimentation. They’ll need to adjust by empowering the teams to make decisions without seeking approval. They’ll need to adjust by being objective and focusing on specific customer and business outcomes. This will take a while.

A huge thanks to all of our attendees, speakers and staff for such a wonderful. Follow @neo_innovation to learn about future events.

[Jeff]

Posted in agile, Conferences, design, enterprise, lean startup, Lean UX | Leave a comment

Building In-House Innovation Teams: When to Stop Innovating and Start Scaling

Should you hand off?

Should you hand off?

In parts I and II of this series I discussed the qualities that make up successful in-house innovation teams and the need for those teams and their colleagues to foster a culture of transparency if they are to succeed. In this article I want to discuss how to decide when these in-house innovation teams need to shift their focus from pure innovation and move into scaling. More so, I want to discuss whether these teams should continue into scaling or hand off their work to a different team.

Continue reading

Posted in agile, enterprise, lean startup, Lean UX, Productivity, ROI, work ethic | Leave a comment

The Human Cannonball – A Story of Untested Assumptions

In May of 1995 I graduated from James Madison University with my bachelor’s degree. It was a Saturday. On Sunday I packed all of my worldly belongings (essentially a mattress, a dresser, a Bob Marley poster and my 1984 Suzuki GS550 motorcycle) into a tiny storage unit. On Monday, I was on the road as the new sound and lighting technician for the Clyde Beatty – Cole Brothers Circus. I always joke that I actually joined to be the bearded lady (I had a lot more hair back then) but, in fact, I was pursuing what I thought was going to be my career – audio production – and this was a paying gig doing exactly that!

 

Clyde Beatty Cole Brothers Circus - my home in 1995.

Clyde Beatty Cole Brothers Circus – my home in 1995.

That summer was one of the most unique and interesting of my life. I had many adventures, learned a lot about circus culture (and myself in the process) and met many interesting people. One of the more interesting people in the circus was the human cannonball. In the 18 years that have passed since then I’ve forgotten his name but he was young (though older than me), blonde, fit – essentially an all-American football player type of guy. He was married and his wife was an aerialist performer in the same circus. He worked 4 minutes a day – 2 shows every day that lasted 2 minutes each. He collected about $1000/week I believe for taking the risk of being projectile vomited out of the mouth of a giant truck-mounted spring cannon, flying through the air and landing safely in a net about 100 yards at the other end of the big top.

The human cannonball as he enters the cannon.

The human cannonball as he enters the cannon.

 

I always wondered how he (or anyone for that matter) became the human cannonball. So, finally, one day I asked. I don’t remember who I asked or who answered me but I’ll never forget the story. It began with the previous human cannonball. To prep for the act every night the previous human cannonball (let’s go with HC for brevity) would drive the truck into the big top before the crowds arrived. He’d point the cannon in the appropriate direction and load in a dummy that was approximately the same size and weight as he was. He would launch the dummy, see where it landed and that is the spot where the safety net was erected. It was a simple assumption – “if the dummy weighs the same as I do then wherever it lands is where I will land and that’s where the net should go. “

 

One night the circus arrived at a new location during a thunderstorm. It was raining too hard to set everything up and test where the dummy should go. Instead, it was left outside overnight as torrential rains blanketed the area. The dummy absorbed a significant amount of water. The next morning, before the crowds arrived, the previous HC did what he always did. Drove the truck into the big top, aimed the cannon, loaded the dummy and fired. The dummy flew, landed and the net was erected. That evening, the HC got in the cannon in front of 3500 spectators and launched himself as he’d done dozens of times before. This time was different though. The dummy, soaked with water, was significantly heavier than the HC. This became evident as the HC soared well past the safety net and crash-landed on the circus lot floor. Needless to say this was his last flight. While he wasn’t killed he was critically injured and returned home to Florida to recuperate. While recovering, he tapped the guy cleaning his pool – a former local football player –  to be the next HC. I’m not sure if he shared with him his own fate as the HC and he chose to ignore it or if the seeming glory of the circus spotlight coupled with the pay raise compelled him to take on this new role. Regardless, the baton had been passed on and a new HC was born.

 

The reason to tell this story – besides its inherent uniqueness – is to make you think about the assumptions you make about your life, your business, your designs and your projects. Just because something was true yesterday, doesn’t necessarily mean it’s true today. Things change – sometimes without you noticing – and can have a significant impact on your activity. Stay skeptical and keep checking even your most basic assumptions. It turns out these basic assumptions are actually the most critical and potentially life-threatening.

 

[Jeff]

Interested in seeing how large organizations are building lean, innovative teams? Learn how to implement Lean Startup and Lean UX from PayPal, GE, Intuit, The Weather Channel and many others presenting case studies and workshops at Lean Day: West. Tickets on sale now. Now, get $100 off with code: blog.

Posted in agile, enterprise, lean startup, Lean UX, prototyping, Uncategorized, work ethic | Leave a comment

Building In-House Innovation Teams: Transparency

transparent_fishIn the first post of the series I discussed the basic building blocks of a successful in-house innovation team: small, dedicated, collocated and self-sufficient. In this post, I’m going to talk about a key philosophy for these teams: transparency. It’s not in our nature to be transparent in the business world (or in the personal world for that matter). From the baseball diamonds of little league to the lecture halls of business school, we’re taught to be competitive and to push ahead of our colleagues. After all, it is our individual ideas and skillsets that define the quality of our work and our discipline and set us apart from our colleagues. How can being transparent – with our thoughts, our tools, techniques and ideas – possibly help us excel as individuals, as a team and as a company?

Transparency at the individual level

The first place to start, as with all of life’s improvements, is with you. Regardless of your core competency – design, engineering, management – sharing your ideas and techniques with your team early and continuously brings a whole host of benefits.

  • Validation of your ideas – making your ideas public early gives the team a chance to weigh in and provide their insight into the feasibility, relevancy and validity of your thinking. This, in turn, saves you time by keeping you from exploring ideas that don’t align with the team’s vision or scope.
  • Collaboration – the act of sharing by itself begins a dialogue with at least one other person on your team. As that conversation, and that technique, spread beyond that initial action a spirit of collaboration takes root. In addition, you are seen as someone to whom others can seek out for feedback and further collaboration.
  • Thought leadership – transparency shows you’re actually getting work done (we all knew that, but it can’t hurt to show it). If you’re working on the project then you’ve likely generated ideas on how to approach it or solve the current problem. This paints you as the “idea person” and someone who has put in the time figuring the challenge out.
  • Source of inspiration – Your ideas, now visible to everyone on the team, serve as a starting point for feedback and discussion as well as inspiration. Teams react to initial ideas, even if they’re straw men, rather than blank whiteboards. In addition, your efforts at being transparent may inspire others on your team to be more forthcoming with their early thoughts.

Transparency at the team level

Teams, especially those trying out new ways of working, benefit greatly from open-sourcing their processes. In many ways, without even trying, transparent teams become mini-R&D units for new thinking, processes and products. This recognition would be far more difficult to come by if the team closely guarded their internal IP. In addition, team transparency brings:

  • An awareness of new techniques – if some of your colleagues could benefit from a new customer interviewing technique you’ve used or a way to measure the impact of certain architectural changes, hold a brown bag lunch and demo your new technique. Letting others see what your team is doing and how it’s working (good, bad or otherwise) saves them the time it would take to learn those things on their own.
  • Consistent status updates for managers and above – nothing makes managers more anxious than not knowing what their team is currently up to. Using techniques like daily standups, weekly status updates, information radiators reporting back on the team’s success metrics, and weekly demos your managers will always be ready to answer their boss’s questions about your progress – which will keep them out of your way. Nice.
  • Comfort with a team’s progress (especially if measured differently) – I talk a lot about lean teams and how they should be measured against business outcomes, not a specific output. This new way of measuring is difficult for managers since it is not binary (e.g., did the feature launch or not?). By ensuring your team is consistently communicating their progress against their targets (even if the progress is not good) it gives your manager a sense of how you’re progressing. In addition, it’s important to let your manager know what you’re working on this week, what the backlog holds for the next iterations, what you’ve learned in your recent experiments and what you hope to test next.
  • Reduction in road blocks for colleagues and other departments – the marketing department wants to know when you’re launching new features. The customer service folks need to know when workflow updates are going live. These folks are not trying to get in your way. They’re trying to do their job. Make it easy for them (and for you) by always communicating to them what you plan on releasing, when and how it will affect their day-to-day work. This holds true for any department that’s dependent on the product you’re developing.
  • Greater sense of pride and accomplishment – if your team succeeds and has been transparent about how they succeeded, they can continually point to those successes as proud accomplishments. That sense of pride is contagious. Other teams will want it and will reach out to your team to understand how you did it and perhaps even ask you to help train their crew.

Transparency at the department level

The word department is often synonymous with the word silo – especially a discipline-specific silo. There are other types of departments though – usually product lines or industry verticals serviced by the organization. Transparency at this level – regardless of the type of department you work in – can have a dramatic impact on the way the organization perceives your department as well as the impact you can have on the organization itself. By making the company aware of the processes your teams follow, sharing insights into the specific tactics those teams use and broadly posting the various teams’ progress towards specific business objectives your department can become a vision of what the future holds for the rest of the company. Let’s take a look at some specific impacts.

  • Hiring brand – every department wants to hire the best practitioners. Being transparent about how you achieve great results, what kind of empowerment employees have and how everyone is measured and rewarded indicates a level of trust that many A-players value. It clearly indicates that your department does not micromanage and allows employees to push boundaries without fear of retribution.
  • Thought leadership – as the organization learns more about what your department does and how it’s faring in its business efforts the perception grows that this is the department that is leading the organization both on domain expertise as well as process.
  • Greater effect on company/product strategy – the mythical “seat at the table” becomes a far more realistic achievement for your department when your leadership understands what it is you do and how you do it. In addition, there is a greater confidence in the strategic suggestions your department makes to the organization because it is based on widely-available learnings you’ve socialized internally.

Transparency at the company level

Transparency at the organization level works in two directions – internally to your employees and externally to your customers. For the purposes of this article, I’m going to briefly focus on internal transparency. For external transparency and other insight into how to build successful companies you should read Dave Gray’s The Connected Company.

Internal transparency gives your employees a clear sense of how the business is doing and how their work is impacting that success. It motivates them to fix problems they can clearly see impacting revenues, customer satisfaction and other success metrics. It demystifies the “executive layer” and shows the rationale behind the decisions that come down from the C-suite. Finally, it encourages employees to be good corporate citizens and to dig into business intelligence data to find opportunities for improvement or to diagnose the root causes of problems they are tasked with fixing. Ultimately, it shows your teams that the company’s leadership trusts them.

Successful innovative teams and companies share their learnings. They share their successes and their failures. They’re honest about what they’ve tried and what they’ll try next. They build collaborative eco-systems that feed fast learning cycles and cross-pollinate innovative insights across the organization. It’s this transparency – at the individual, team, department and company levels – that empowers innovation teams to succeed.

Have some good examples of transparent teams and organizations you’ve seen or worked with? Share them in the comments below.

In the next post in the series, I’ll discuss how to decide it’s time to stop innovating and start scaling your solution.

[Jeff]

Interested in seeing how other large organizations are building lean, innovative teams? We’ve got PayPal, GE, Intuit, The Weather Channel and many others presenting case studies and workshops at Lean Day: West. Tickets on sale now. Now, get $100 off with code: blog.

Posted in agile, enterprise, lean startup, Lean UX, Productivity, ROI, work ethic | 2 Comments

Building in-house innovation teams: Small, collocated, dedicated, self-sufficient

One of the most common questions I get about applying lean ideas to product design and development is, “How can I make this happen in my organization?” Between entrenched corporate silos and existing team management structures it can seem impossible for these ideas to take root in large companies. Over the course of a series of blog posts, I thought I’d share a few tactics I’ve used and have seen work with other teams to help get you started. In this first post in the series, I’d like to talk about how to structure your teams.

As much as who you hire, structuring your teams effectively is key to a lean team’s success. Many companies see the individual disciplines in their product development organization as service providers – internal agencies. The business reaches out to these agencies (engineering, UX/design, product management, et al), expresses a need for staffing and the discipline lead provides the resources based on expertise, availability and project fit. It sounds like a reasonable and efficient way to staff a project and to that extent it is – however, our goal should not be to simply staff a project but to build a team.

When building your team focus on the following four criteria to maximize their chances for success:

1. Small

Keeping your team small means everyone on the team knows each other – on a first name basis. It’s easier to manage a small team. It’s simpler for the team members to know who to go to when they need something specific. It’s easier to keep track of work accomplished and work left to do.

Small teams tend to self-organize faster and more effectively. They recognize the impact of mistakes and work quickly not to repeat them. They hold each other accountable (because they know each other) and build up a level of trust, across disciplines, due to a closer level of cooperation.

When thinking of size, consider Jeff Bezos’ mantra of the “two-pizza team.” That’s a team that can be fed with two (American) pizzas. In terms of numbers, this works out to somewhere between 6 and 10 people. Successful teams I’ve worked with have typically broken down these roles into:

 

-       1 UX Designer

-       1 Product Manager

-       4-5 engineers

-       1 QA

 

Additional roles have included a visual designer, copywriter/content strategist, a marketing person or a subject matter expert.

2. Collocated

The easiest way to get a question answered is to stand up, walk over to the person who can answer it and ask. Collocated teams are simply more efficient. They can share physical artifacts in real time – like kanban/scrum boards, whiteboard sketches and paper prototypes. They benefit from non-verbal communication. The opportunities for ad hoc communication are greater while the chances of serendipitous moments also grow.

Collocated teams can build a “space” together. That space becomes a part of their communication cycle. Artifacts are posted on the wall. Information radiators (like analytics dashboards) give the team a real sense of how they’re progressing towards their goal. And it’s by working in this space together that the team generates their momentum and energy. When it’s humming, that energy is contagious and can infect the rest of the teams in the office.

I’m well aware that many of us don’t have the benefit of 100% collocated teams. Innovation with these teams is, of course, still very possible but it will require some tools. I’ve covered that topic at length here.

3. Dedicated

Dedication to one team seems to be a common problem – especially for designers. For some reason, there is a widely-held industry taboo that developers can only be assigned to one team but that designers can easily handle multiple assignments at once. This is patently false. The costs of any team member supporting more than one team – context switching, prioritization, additional email churn, etc – often end up costing much more than the added productivity multiple assignments seems to bring.

Think of it this way – a designer (or developer, product manager, et al) assigned to working on three teams is pissing off two people every day. That person has to choose which of three number one priorities she will work on each day and then explain to the other two stakeholders why she won’t be working on their project today. So, in addition to inefficient use of their time, the designer is now placed in the awkward position of navigating corporate politics or conversely working 18-hour days to satisfy everyone – neither of which is a good option.

People dedicated to one team get the opportunity to focus. They know how to use their time – because their P1’s are clear. They don’t have to put off colleagues on one team – who are likely waiting on their work – to do work for another team. They produce better work and they do it more efficiently. Also, by focusing on the same problem statement consistently there is a greater chance for innovative breakthrough as opposed to the “just get it done so I can move on” attitude of managing multiple stakeholders.

4. Self-sufficient

One of the most important assets of an innovative team is the ability to do what it needs to do when it needs to do it. Dependencies on other teams slow down the experimentation process, affecting momentum but more importantly, learning and progress. By staffing teams with all the competencies they need to achieve their outcome, you relieve them of many constraints that hold up traditional teams.

Self-sufficient means different things on different initiatives but at the core there should be representatives, at least, from engineering, product and design. If your project interfaces with a unique system or requires insight from a discipline outside of the core three, by all means add it but keep in mind our two-pizza team size limit. Often, self-sufficient teams that adhere to the small team size employ multi-faceted individuals. They are people who can design and run a research study or develop on the full stack. The greater the competencies on the team (not the roles necessarily) the more self-sufficient the team will be.

As you start to build your innovation teams consider these four attributes. They serve as a good set of guidelines for the initial team structure. Over time, the unique context of your organization will morph this structure into one that makes the most sense for your company. However, I urge you to keep the underlying goal in mind as you modify this approach – what can we do, as an organization, to make it as easy as possible for our teams to succeed?

In the next post, I’ll talk about the need for 360 degree transparency. Until then, please add your thoughts and questions in the comments.

[Jeff]

Interested in seeing how other large organizations are building lean, innovative teams? We’ve got PayPal, GE, Intuit, The Weather Channel and many others presenting case studies and workshops at Lean Day: West. Tickets on sale now.  Now, get $100 off with code: blog.

Posted in agile, design, enterprise, lean startup, Lean UX, Productivity | 7 Comments

Sneak preview rate expires very soon for Lean Day: West

I just wanted to drop everyone a quick note to let them know that the sneak preview pricing for Lean Day:West expires in 3 days – June 6th. After that, prices go up to the next tier – a $200 jump.

 

If you’re interested in learning how to apply agile practices and lean startup in the enterprise – from people who are actually doing it on a daily basis – this conference is where you want to be.

 

Check out the amazing lineup of speakers we have from companies like GE, PayPal, Intuit and The Weather Channel and join us, at the sneak preview rate, in Portland this fall.

 

Details and tickets here: www.leandaywest.com

 

[Jeff]

 

Posted in agile, Conferences, lean startup, Lean UX | Leave a comment

Announcing the lineup for Lean Day: West 2013

Lean Day: West - Portland, OR, Sep 15-17, 2013

Lean Day: West – Portland, OR, Sep 15-17, 2013

We’ve put together a truly amazing lineup for this year’s Lean Day: West conference. If you’ve been struggling making agile work in your organization and have been interested in how to apply lean thinking to your product development process, this event will shed light on those topics and more.

We’re kicking off the event with a pre-conference workshop on Sunday, September 15 with Jessie Shternshus. Jessie weds her lifelong passion and expertise in applied improvisation with the fast pace and ever changing demands of the corporate world. Her workshop is designed for developers and designers enabling them to become better listeners, team players, problem solvers, innovators and collaborators. It’s also a lot of fun.

Day 1 of the conference will feature 4 workshops while Day 2 will feature full-length talks by the workshop facilitators as well as a few other special guests. Check out this lineup:

 

Andrew Crow and Dan Harrelson from GE will lead a workshop on designing systems for scaling in large organizations. Andrew will give a talk about that subject as well.

 

Lionel Mohri from Intuit will detail how Intuit builds a culture of innovation and design thinking in his workshop and in his talk.

 

Bill Scott and Cody Evol from PayPal will walk you through how applying lean thinking to their engineering stack allows PayPal to move from design to prototype to product seamlessly.

 

Farrah Bostic, founder of The Difference Engine – who gave a phenomenal talk at Lean Day: UX – is back again to reprise that talk on lean research techniques and to teach a workshop on the topic.

 

Emily Holmes from Hobsons will discuss how small, incremental wins have helped her team gain a stronger foothold in her company’s product development process.

 

Ben Burton and Jono Mallanyk from Neo Innovation get specific on how designer/developer pairing has worked for them and what tactics have made them one of the most productive duos we’ve come across.

 

And out latest additions, Aaron Sanders from Co-makers and Jeff Hutkoff from The Weather Channel will talk about how, with the help of an outside coach, they were able to overcome years of corporate momentum to release and continuously improve The Weather Channel’s flagship mobile application.

 

This is a conference about tactics and techniques. It’s about applying lean startup, agile and lean ux in the enterprise. Our all-star cast of speakers is living this stuff daily and will be in Portland in September to share their insights with you.

Join us!

Tickets on sale now at www.leandaywest.com

[Jeff]

Posted in agile, Conferences, design, enterprise, lean startup, Lean UX, Productivity | Leave a comment

Lean Day: West – a conference for innovative product teams

Portland, OR

Beautiful city, beautiful mountain.

I’m thrilled to announce the next event we, at Neo, are putting on this fall. Lean Day: West will take place September 16-17, 2013 in the gorgeous city of Portland, OR.

Building off the momentum of Lean Day: UX, held back on March 1st, 2013 in NYC, this event is expanded to 2 days and will offer workshops and talks about practicing lean startup in the enterprise.

Continue reading

Posted in agile, Conferences, enterprise, lean startup, Lean UX, Research | Leave a comment

Designing with remote teams

I will be speaking on working and designing with distributed teams at this year’s IA Summit in Baltimore, MD.

remote teamsAs the author of a book on collaboration – a book that touts the benefits of collocated teams – the reality of distributed teams is not lost on me. In fact one of the main questions I get asked each time I present on Lean UX is how to make it work with remote teams. While the benefits of in-person collaboration and communication are clear, it doesn’t mean they can’t be achieved with remote colleagues.

 

There’s been no shortage of coverage lately about the different strategies companies employ when it comes to their distributed work force. Certain companies, like Automattic – makers of WordPress, have an entirely remote workforce and swear it’s the only way to work. Other companies, like Yahoo!, have made headlines recently when CEO Marissa Mayer demanded all remote employees come back to the office. LivingSocial has promoted a distributed team environment under the leadership of now-departed SVP of Technology Chad Fowler. The poster children for distributed teams, 37 Signals, swear by this approach to the point that they’ve written a book on the topic. What has been missing from the conversation to date is context – the context of the work these companies are doing and the context of their current environments.

 

Let’s look a little deeper.

Continue reading

Posted in agile, design, enterprise, Lean UX, Productivity, Uncategorized, ux team, work ethic | 15 Comments