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.
In 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.
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.
In the second part of this two-part series on adding game mechanics to Agile (read Part 1) processes, I want to discuss limiting the amount of cards a team has “in flight” at any given time.
By in-flight, I mean cards that are actively being worked on by developers. Limitation is defined as not taking another card from the backlog until there are less cards being actively coded than the limitation. Specifically, consider limiting this number to one less than the number of developers you have on your scrum team. There are several benefits to this technique. Here are three:
Seems like everybody wants to gamify everything these days. Far be it for me to not jump on this bandwagon as well :-).
When properly harnessed, adding game mechanics to certain processes can make them more fun, engage the team performing them and increase the productivity and quality of output from that team. As we continue to evolve our Agile practices, we’ve experimented with some game mechanics to see what, if anything, is effective in increasing our velocity as well as the quality of our work. In the inaugural post of this series, I’d like to show you how aging your feature cards can help your team focus and unblock itself.
“What are you going to do this weekend?”
“I’m going to hang out in the Financial District with a bunch of folks from various disciplines and locations to discuss the intersection of Agile and User Experience.”
“All weekend? Um, that sounds like fun.”
As it turns out, it was a lot more than fun.
More than 20 people gathered this past weekend at Pivotal Labs’ temporary NYC offices to conduct the next installment of the Agile UX Retreat. With previous retreats taking place in San Francisco, Grad Rapids and an impromptu one in Orlando during Agile 2010, this one brought the ever-growing crew to New York. And I was fortunate enough to get an invitation.
In true agile, self-organizing fashion there was little up-front agenda presented. Instead the participants gathered together, provided their desired topics and discussions, the group voted and formed an agenda surprisingly fast. The first evening consisted of a night for newbies. Us first-timers were encouraged to get to know the returning participants, share a bit about ourselves and to start building relationships with the (instantly evident) tightly knit crew. Folks came in from San Francisco, Seattle, Chicago, London, Brooklyn and Michigan (to name a few) emphasizing the dedication the participants had to pursuing the topic of Agile and User Experience. Friday night’s discussions focused on the tactical facilitated by a “fishbowl conversation.” This was a new facilitation technique for me and involved providing 4 chairs at the front of the room. Only 3 chairs can be filled at a time and the participants in the chair have a conversation with each other. A seed question is proposed and the conversation begins there. As other participants in the room feel the desire to join the conversation, they simply walk up and sit down. At this point someone from the panel has to step down. One chair must always stay empty.
In this way the conversation grows organically and weaves a meandering path through each participant’s viewpoints and topics of interest. We covered tactics, philosophies and the broader arena of organizational change. We got to know our fellow participants without the need of roles or titles – simply through their opinions and arguments. It was refreshing, engaging and rewarding.
Day two provided opportunities for discussions and talks. As before, topics were proposed, voted and prioritized. Some folks had prepared talks (like me), others simply had ideas they wanted to share and discuss. It was a long day filled with tactics, philosophies and theories about how to drive change through organizations from the bottom up as well as from the top down.
At the end of the second day we held a retrospective to see what went well, what went poorly and any outstanding questions. My main point of contention was the fact we had seemingly few points of contention. The constructive conflict that should drive folks struggling to rationalize new philosophies in existing structures and organizations was missing. In its place was a room full of nodding heads (and waving hands J ). I was concerned we were all preaching to choir and not doing enough to move the discussion forward. Interestingly, everyone agreed with my point that we were very much in agreement but many disagreed that this was a bad thing. Instead, several folks called this general agreement a sign that the group had become unified and could now begin pushing its message beyond the retreat’s boundaries.
Which led nicely into the third and final day’s discussion topic: getting the message out. But what exactly was the message? And who should we target with it? This was part of the third day’s conversation and the general consensus was that promoting organizational change to create cultures that support collaboration, conversation, fail early/fail fast product design philosophies should be a primary focus for the group. Proving, ultimately, that this approach delivers better products, faster, to happier customers resulting in engaged, invested employees who are trusted by their managers. And what better way to do this then to hold a conference? The room focused on early stage planning for such an event and I look forward to continued efforts to bring it to life next year.
I took away many things from the weekend, not the least of them were new friendships with folks I’ve admired for a long time. What surprised me the most though (and perhaps this is a little bit self-serving) was the group’s reaction to the work we’ve been doing at TheLadders in the Agile and UX space. We’ve been evolving and iterating our process for 2 years now and it’s easy to stay in our isolated world without the context of the broader software industry. This weekend (coupled with the other outreach efforts I’ve been involved in like Agile 2010 and Agile Day NYC) gave me that context and helped me see that TheLadders is at the forefront of a lot of this thinking. We’re trying new and better ways to make products – with great results! Perhaps most enlightening though was my realization that we’ve successfully created the culture that allows us to try these new methods without the fear of failure. We’ve created a culture of innovation. That became clear to me and if that was the only positive outcome of the weekend it still would’ve been worth it. Thankfully there was so much more and I look forward to the next convening of the Agile UX Retreat.
[Jeff]Many thanks to Ian McFarland, Anders Ramsay and Lane Halley for putting the weekend event together.