The answer to the Agile-UX question

Designing the answer to agile and ux

Designing the answer to agile and ux
(image courtesy of Shutterstock)

Making user experience and design work in an Agile environment is one of the biggest challenges facing product development teams today. Lean UX is the most effective way to design a process to solve this challenge. However, there is an even more fundamental and critical transformation your organization has to make in order to facilitate the adoption of Lean UX and solve the Agile/UX question.

Your organization has to value design. 

Adopting Lean UX and ultimately integrating design and agility in your product development process is expensive. It will force changes in team structure, incentives, hiring plans, feature choices, team dynamics, prioritization and many other facets. All of these changes cost something – time, money, morale, political capital, etc. If your organization doesn’t see value in design as the differentiation in your product’s success, it will be very hesitant to pay these costs.

If you’re struggling to make Agile and UX work in your company, ask yourself how willing your colleagues and supervisors are to pay the costs of making this marriage work. If the answer is “not very likely” then your organization doesn’t value design and you’ll never solve the Agile/UX question in an effective way.

[Jeff]

Posted in agile, design, enterprise, Lean UX, Productivity, ux team | 7 Comments

20 years of technology and music – my interview with Carbon Leaf

(Note: This post is a bit of a departure from my usual content. For those who don’t know, there was a period of time where I was an aspiring musician – I play keyboards – and played with a couple of bands that gave “making it” a real shot. During those days, we connected with our local comrades-in-arms Carbon Leaf. Recently, I found myself reflecting on how much things have changed technologically since we were in those bands all those years ago. It inspired me to reach out to my buddy Terry Clark, one of the founding members of Carbon Leaf, and ask what’s changed in the past 20 years of being an independent touring band. His answers are below. Enjoy.)

Carbon Leaf in 1993:

Carbon Leaf - 1993

 

 

 

 

 

 

and Carbon Leaf in 2013:

Carbon Leaf 2013

 

 

 

 

 

1.Can you give a quick recap of Carbon Leaf’s history? How long have you been together?

We started at Randolph-Macon College in spring of 1993.  Basically just as a diversion, with no serious ambitions.  After a few months together, we started writing our own material and really liked what we were turning out, so we stayed together after graduation.  Eventually, all of us relocated to Richmond, VA where our weekend gigs started stretching to three, four or five days long.  We were releasing our own music on cassette and CD, basically selling them (or giving them away) at shows and a few local record stores. In 2002 we had to privilege to win an American Music Award as Coca-Cola’s best-unsigned band.  That opened a lot of doors for us as and definitely introduced us to a lot of people. The following year, 2003, we signed a record contract with Vanguard Records and released 3 albums through them. During this period, Carbon Leaf was fortunate to have a couple of successful radio singles that really helped put our music into a lot of new ears. In 2009 we left Vanguard and restarted our own label, Constant Ivy Music, and have released 5 new projects to date… including 2 full length albums in 2013: Ghost Dragon Attacks Castle and Constellation Prize.  We have always been “road dogs”, touring our butts off – to the point of wearing out five vans and three trailers.

2.When you first started the band, how did you get the word out about shows?

When we first started the band, promotion involved a lot of flyers stapled to telephone poles and mailing out physical postcards to our fans.  We used to sort our mailings by zip code in an effort to get a bulk mail discount at the Post Office.  In short, it was incredibly time consuming and a pain in the ass.

3.In the early days, how did you make records? How did you distribute and sell them?

Our first recording was a 4-song demo cassette recorded at a friend of a friend’s home studio.  That was the dawn of relatively in expensive digital recording.  He had and 8-track studio consisting of a Tascam DA-88 and a Mackie board… pretty revolutionary for the time.  Duplication was accomplished at our apartment with a stack of 5 daisy-chained cassette decks.  It was an art to push play on one deck while simultaneously pushing record on 4 other decks!  We gave away cassettes by the bag full at shows, generally throwing them into the audience from stage.

 

Shortly thereafter, I got an entry-level job in a “real” recording studio in Richmond (In Your Ear).  I was allowed to record at night to figure out how things worked and to try to learn the art of production.  All of the engineers there pitched in a great deal and helped me immeasurably when, in 1995, we started what was intended to be a full-length cassette.  It turned out that CDs were cheaper than cassettes at that point, so the project really became our first CD – Meander.

 

As a bit of a recording footnote, we were using one of the first professional hard disc recording systems, The New England Digital Post Pro.  It was 16 tracks on four separate hard drives in an enclosure the size of a refrigerator… it cost $250,000 and weighed 600 pounds.  Seriously.

 

The CDs we sold at shows and on consignment at local record stores.  Almost all of those stores have since closed :-( and the biggest one has filed for bankruptcy.  They still owe us a little money, so we receive copies of all the legal proceedings… it’s pretty sad.

 

A few years / albums later, we signed on with a large independent distributor and they were able to get or CDs into a lot of store throughout the country.  Some time goes by and it seemed like we should be getting more money from them, so we hired an accountant to audit them.  It turns out they owed us $80,000.  Awesome.  Needless to say, we are no longer with them.

 

 

4.How effective were these early promotion tools? (i.e., how much return did you see on the time/money you spent on these tools?)

Our flyer and postcard promotions were kind of successful… gradually more and more people started coming to shows.  We relied a lot on word of mouth.

 

5.How has the internet changed the way you promote the band? Make records?

Our main goal these days is to communicate directly to our fans through our website (www.carbonleaf.com), Facebook (www.facebook.com/carbonleaf) , Twitter (www.twitter.com/carbonleaf), YouTube (www.youtube.com/carbonleafofficial), SoundCloud, Instagram, etc.

 

We also us a service called Topsin for organizing our email database… allowing us not only to send monthly newsletters to the whole list, but it also gives us the ability to GeoTarget specific areas that we are playing.  That way we can email just our Texas fans about our Texas shows and not have to spam everybody.

 

Through Topspin we can also sell downloads of all of our albums, give away free downloads and sell “official bootlegs” of all of our live shows.

 

A few years ago, we built a pretty decent ProTools based studio at my house and have done almost all of the production there for the last 5 projects. We trade files with people via the Internet using Hightail and Dropbox.

 

6.What role does social networking play in the band’s activities these days?

It’s huge. We try to stay connected everyday to let people know what we have going on and it allows us to easily communicate directly with the fans.  It’s fun and helpful to able to see what our fan like and dislike in almost real time.

 

7.Do you run your own social networking accounts or does someone else run it?

We run them ourselves.

 

8.Do you use technology (of any kind) to “test” your material? (i.e., to see if people like it, will buy it, etc)

Not really.  In an ideal world, we like to play new songs live first, before we record them.  That’s the best way to see if something’s working or not.

9.What’s been the single most transformative technological change, when it comes to keeping Carbon Leaf going, since you started playing together?

Computers.  Not only can we make a really good album on a laptop now, but we can also distribute it to the world, promote it and connect directly to our fans from that same laptop.

 

10.What do you hope to see in the near future for music technology?

Unfortunately, all of this technology doesn’t make the 24-hour van drive from San Diego to Austin any quicker. :-)

 

I’m not sure what is coming next, but I’m sure that it will be smaller, faster, and cheaper and will hopefully further reduce the barriers between our audience and us.

 

 

Posted in Uncategorized | Leave a comment

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