Product and Organizational Bloat

“Life’s too short to build something nobody wants” – Ash Maurya

YAGNI or “You Ain’t Gonna Need It” is a principle of the extreme programming approach created by Ron Jeffries (who coincidently also used story cards as a way to focus development on small items centered around interaction and conversation to gain understanding).

“Always implement things when you actually need them, never when you just foresee that you need them.” – Ron Jeffries

This idea was a cornerstone of a lot of approaches centered around lean product development and agile product thinking. It does not mean that you are not charged when developing a product that may wow and excite your stakeholders but it does mean that there is a real art in the balance of applying “not now” to a feature.

Steve Jobs is often referenced to have a keen intuition to this in guiding the feature sets of Apple products under his watch to often purposely avoid features that were not at a point of making the “right” impact. The iPhone and its lack of a few core features available in competitors is often referenced as an example of this. Why would you not implement features that were core to the competitor’s products on purpose? I am paraphrasing but I believe his response was often “it is less important to build every feature than to build the right ones and that by trying to do so, by the time completed; they will want different features”.

Anyone who has ever seen the Simpson’s episode in which Homer designed his own car (“The Homer“) realizes the potential consequences of doing everything that pops into your head within product development. The end result was a car that was intended to be designed for the “every man” but ultimately became the wishlist of Homer alone with a sticker price for $82,000.

In the 80’s and 90’s Microsoft was often the butt of many jokes within the development and design community for their Microsoft Word product because if every menu was turned on within the product it allowed the end user a small strip of editor window from which to work. Of course, this was a extreme issue to beat on a software leader of the time (and they did have at least 80% of the menus off by default for the most part). The idea though was that by providing all of these features it would allow the end user to control the customization of the product to their use. This is pretty much an old design approach that is far less prevalent as it was often necessary to be coupled with massive help guidance for those features which were embedded into the product at the time as well.

One example I have been tracking recently is Facebook’s feature growth strategy. They started out as a targeted social connector service that streamlined the interface to dominate the competitors in the market . It seems, however, now they are developing a “all services in one” model which may, or may not, pan out to be the right marketing strategy. Let’s look at how their features have unfolded lately:

  • Introduced Facebook Games possibly as a way to attempt to compete within the mobile application game market.
  • Introduced Messenger – Competition for base messaging services and maybe things like slack, skype, etc.
  • Introduced Facebook Live – Competition to other video sites such as Youtube, etc possibly.
  • Recently introduced Facebook marketplace as an alternative to Craigslist, etc.
  • Developed a phone OS to compete with Apple, Android, Google.

I think that this pattern outlines a platform that is in search of the next pinnacle. All of these services also are a way for them to feed a highly developed analytic engine that can determine the trends of users and try and guide them down a pathway based on interests. Not a bad gamble as the likelihood that you will find a segment of the market space dissatisfied with a service they are matching and willing to even just try it based on the familiarity with the Facebook platform is a solid gamble. In this fast pace environment, people like to do things with minimal friction (a later blog topic) so you will capture a market.

The key will be watching the numbers to determine if it is important to continue this feature, Google has been a master of this approach and has supported and abandoned entire products that had a minimal market share and I think Facebook will apply the same watchful nature to know when it is time to pivot or persevere. But only time will tell. ūüėČ Will the expand and rule some of this space or will they diffuse and diverge to find something else?

You may be thinking “are you telling me I should just build a simple, crappy product and not cultivate the product. How is that gonna fly”? This is not my intent.

Ideation is a Great Tool!

The Google Ventures Design Sprint outlines the following process (also seen in many Lean approaches) to validate and learn about feature impact as well as gain immediate feedback within a fixed horizon process (in their process this is typically one week).

  1. Understand
  2. Diverge
  3. Converge
  4. Prototype
  5. Test

Phase two of this process is centered around divergence after a period of gaining understanding of the problem space. What this entails in mass generation about potential solutions to the problem. The goal is to center around the largest number of potential solutions so that the design sprint team can cull/collapse and combine in the convergence phase to focus them for the prototype creation.

This idea of mass idea flow is not unsimilar to product feature ideation during product discovery. It should always be the goal of a product team to thinking about all the potential end user “wow” features or how they can present features in the best user experience. However, there is a dark side to all of this. You have to be able to do the same as a design sprint and cull the herd. It’s a necessity to explore and examine the potentiality of the product but it is also a real art to being able to refine the feature set down to a manageable level that maximizes impact, value and learning.

The challenge is typically not with the ideas but the skill in which those ideas are refined, combined and reduced to maximize time to market, customer joy and lay the groundwork upon which to continue to delight.

Less is More

Often as an agile leader, I am faced with the pressure of more “wants” than capacity ever allows. The worst thing I can possibly do is to say “Yes” to everything. What are the possible consequences of this posture?

  • I set a false expectation for delivery as I do not consider the capacity of what can actually be delivered.
  • I may compromise the quality of the work through a consideration of over-commitment resulting in additional rework, staff burnout or injured morale as a result of staff over alignment.
  • I remove the ability of my organization to pivot, persevere and re-adjust to organizational needs that emerge and respond as timely as possible.
  • I add the overhead of support as a hidden cost if the same staff are used for build and run operations.
  • I disallow myself the ability to continual nurturing of the culture by having horizons to focus on self learning and innovation outside of product delivery space and therefore stand to harm accepted cultural values of my group.

What my typical stance as a leader is to “do less better”. Does this mean I am unwilling or inflexible to the needs of the organization? Of course not. What I am unwilling to do is to place the health and potential damaging impact to my unit culture as a balancing point to accomplishing what is often just a “wish list”. I try and focus a view of being reasonable and responsible to my organization in terms of their needs which should also to be to keep a happy and healthy work culture intact so that capacity is not constantly in flux resulting in the overhead of onboarding and offboarding employees, morale reduction and taking away the value of the team making commitments to delivered work and respecting the commitments they make.

Many of you are reading this now and thinking “this guy works in a fairy world” but this is far from the actual case. I am a leader inside a large scale enterprise and experience the same pressures and demands as many of you. Where our thoughts may diverge is that I have to look at not only the bottom line of the enterprise but the health of staff and adherence to values to continue to be successful. It is not enough to “deliver cool stuff” if you work/life balance or work/life integration (moreso today) is overwhelmingly in the work category to an unhealthy level. The result will be a culture in which commitments become less valuable, end results become compromised and the health of your organization suffers.

Many startups have learned the harsh lesson that after the thrill of creation is done, all of the beer taps, ping pong tables, office hammocks and cool factor can wear off. These are unsustaining items of value. They are tangible things that people are enamored with as a “great environment” but later ask “is this why I stay here”? Not to say that your environment should not facilitate the best and most productive inducing experience but if that is the level of commitment by a company, this is usually seen through by software professionals over time. They look for something else. Cool challenges will keep them for a while but when the routine work sets in, what tangible things have you offered that make them want to stay?

 

But I am getting off track here. Basically this idea boils down to a belief that by not putting one’s organization in a state of over-commitment, you allow yourself to consistently wow your end customers with the things that you do produce.

When targeted your features, you build in the possibility of innovative thinking spikes in creative work and give support to failure and regrouping as an option. You make quality something that is baked in and not an afterthought.

So when you think about product features and organizational commitments and bloat, are you looking through the lens of YAGNI? What would happen if you did so?

Stay Agile!

Advertisements

Draw How to make Toast

Just a quick redirect to something I have stumbled across and found fascinating and wanted to share. This approach is an introduction to systems thinking and what they call “Wicked Problem Solving”. This is another approach from Tom Wujec who outlined another team approach to iterative innovation in the Marshmallow Challenge Website.

I just found this a very interesting way to get to core problems to solve for a group. Check it out:  Draw How to Make Toast Website .

Hope this gives you another tool in your agile toolbox to do great things!

Unplanned Interactions

“Make your interactions with people transformational, not transactional” – Patti Smith

I have been preoccupied lately with organizations and their culture. I find it fascinating ¬†how sometimes decisions with the best of intentions simply turn out wrong whereas sometimes a simple “nudge” in a direction with the freedom to shape an outcome that realizes a clear end goal or principle. Maybe I am so fascinated by this as it often seems elusive to me as a leader or maybe I just have not cleared my mind enough to be that intentional.

The reason I am taking a moment to write today is that I heard a phrase that seemed universal in building solid organizational cultures; unplanned interactions.

The phrase challenged that to really create unity inside a culture that creating space and opportunity for these unplanned interactions between people of any level in an organization create heightened unity.

The idea is that for the most part we, as humans and workers for a company, often see the same obstacles and opportunities but alone in our bubble many feel powerless to act upon them. But as a shared experience, creativity towards solution or change can have an opportunity to flow. How many times have you found yourself engaged with a stranger in a conversation and some subject that sparks you both arises to create a situation in which you build on an idea, experience healthy conflict from opposing opinions or just become more engaged as you are sharing and learning things you did not know?

This concept also supports the idea of cultivation of “informal leaders” or what I often refer to as “leading where you stand”. People begin to think of new and creative ways to better the world around them. For the most part, people want an engaging and positive workplace since we spend a great deal of our lives there. Most seek to make it better. Often people experience fear or lack of empowerment to do so through self-imposition, bad management or general organizational constraints that inhibit making change. Sometimes based on these constraints, we allow ourselves to become derailed to make any change as it doesn’t seem the optimal. I know this very well as I often question myself regarding change I make if a deviation from the ideal (although it rarely stops me).

So, back to this idea of “unplanned interactions” … ¬†Does your organization create a way to support this? Typically we facilitate lots of planned interactions in organizations such as company picnics, Christmas parties, pot lucks, etc. But those can often create the stereotypical middle school dance situation in which people gather with people they know to enjoy the event as a shared experience. We do things like place cards at tables to mix people together but it often does not have the desired outcome. Why? Is it because it is an attempt at compliance to interact as opposed to facilitating the space to interact? I absolutely think that organizations should create planned interactions as a part of their culture as I think it familiarizes people with new faces. We just have to ensure that we take care not to make them something people feel mandated to take part in.

I really am curious about how to create space within my organization to facilitate connections. We have two distinct business groups (which have different cultures), but in speaking informally with people in both, there are shared passions and opportunities to engage in playful ways to connect people within the two. Perhaps we have to be brave enough to break from social convention and create and encourage playspace as an effort to create a more holistic view of our organization? It really has me thinking and wanting to learn more and try some experiments to see if we can foster these interactions. I think that by doing this we are looking at our organization with more of a systems view (from individual to team to department to division to whole) and stand the potential to tap into the creative minds that lay dormant inside our organization.

So I put out questions and a challenge to everyone who reads this. How are you facilitating unplanned organizations between individuals today? And if you are not presently doing so, why not? Or, how can you start? As always, I hope you change the world…

“When you want something you have never had, you have to do something you’ve never done” – Steve Roesler

 

 

hackIT Code Week

 

“If you cannot fly, then run. ¬†If you cannot run, then walk. ¬†If you cannot walk, then crawl. ¬†But whatever you do, keep moving forward” ¬†-Martin Luther King

Well, the day is finally here! hackIT code week is happening!

The plan: Create a timebox for development team members to generate ideas based on things they seek to explore, form teams around them and build their ideas.

The Outcome: Demo day of built product ideas at the end of the week to peers and other organizational staff. Votes are cast and the first hackIT winner is declared.

The general rules:

  1. Place any ideas that you want to solicit team members for on the Shipit board.
  2. You have until to 2/25/2016 to declare your hackIT project idea and your team
    NO PRE-CODING, PLEASE РLET’S KEEP IT COMPETITIVE!!!!
  3. You can be a single person team but not a part of multiple teams
  4. Your code must be FUNCTIONAL for a demo during lightning talk.
  5. Keep it small and manageable to build in a week!
  6. Ideas related to the business are encouraged, but not specifically required.

We seeded the idea about 30 days prior and asked folks to begin thinking about ideas and soliciting for team members to join them, combine ideas and generally find out what creative “itch” they felt they needed to scratch. In retrospect, this was perhaps a bit too long but I did so as not to distract them from their current product commitments as much. Plus, coming up with an idea sounds easy, but can really be very hard when the end goal is to commit to that original idea. So I think it worked out well.

We had several ideas emerge including several hardware/software products, mobile apps, a scheduler system for operational support and a driving game that allows control of a website from a mobile device as a steering wheel.

So, why did I do this?

Simple; I strongly believe in a few principles as a part of how I am wired to work and think:

  1. I believe in the power of putting togethe r creative people to do amazing things and I have complete faith that this happens when you follow this principle
  2. I believe software development is a creative art and as so those who do it are creative people and need space to be creative.
  3. I love my teams. I love the fact that they are composed of diverse individuals who can come together and share a common set of values yet still hold onto the diversity that makes them individually amazing people.
  4. I believe that if you truly want to be innovative, you have to make space to do so. Trying to force innovation in the midst of the daily “getting sh*t done” is like just digging and believing that¬†eventually you will strike gold. Building the right culture of trust and responsibility, leveraging the creative minds you hire and creating opportunities to let them explore, connect and cross-pollinate. This is where innovation truly happens. Expecting that people will merely be innovative without the time to do so, ¬†a culture of experimentation and a lack of fear in failure is not reasonable. Creating these opportunities is where you find the best potential for innovation.

So, what came out of hackIT?

I expect you want to tell you about all the amazing innovative products we designed as a part of our BETA test for an innovation ¬†event. Well, guess what? I can’t. ¬†We had some amazing product ideas and technical approaches come out of it, but in my eyes that was not the largest value of our first attempt. What happened is we continued to commit to our cultural values and I observed that we were being true to what we said we believe. We had fun, we learned and we continued to connect in doing the thing we do.

How so? Let me give you some of my observations …

Team members just formed functioned as long standing teams.

Because we have been¬†serious and deliberate about defining the way we work and have created a culture that supports the core values for our group and the way we work, we share a common language of working. Teams formed their own ideas and then formed around the idea based on the desire to make it happen. That intrinsic motivation on each team member’s part to see the thing they chose to build coupled with team approach to development led me to observe team members working together and supporting one another that may have never worked together before.

We helped share some of the ideas of how we work with other areas of the organization.

At least one team was composed of team members that were composed of members from an area of the organization that does not have the cultural definition nor work like we do in product development. Feedback from this group was that it forced them to think in different ways. They admitted that they are usually a group that plans a lot before taking action and were unable to do so in this case. They said they learned a lot from the value of small horizon experimentation and build approaches. Plus we continued to build relationships with others and expose them to things we believe.

We had unintended effects.

Groups outside of product development began to become excited about hackIT. Our human resources group showed up to see the event as well as people from other areas of the business. They all wanted to see what we were trying to do. The idea that I was so personally passionate about started to organically grow and ask people what they could do to sponsor innovative space for their own groups.

Following our demo day, I returned to my office a little spent from all of the event (and collecting my thoughts before going for a beer with the teams to celebrate) when several people came to visit me. A few came by inspired by the creativity shown from the event and wanted to express their admiration for a particular product idea but one stuck with me as an unexpected side effect…

I had a person from one of our shared service areas come and relay this to me …

“I just wanted to come by and tell you; product development is not typically ‘my thing’ but I really enjoyed today. It made me proud to be a part of a company that has that kind of people working here”. I told him that this was one of the best compliments we had received and I would pass this along to all of the teams.

The hackIT Retrospective

The next week, I held my bi-weekly staff meeting. Typically this meeting is owned by the product development teams with me as the director just providing some housekeeping items to kick it off and wrap it up. It’s a space for them to reflect on what they are doing and learn from one another. They had the space to design it that way and it works well.

However, some of the development leaders said we should reflect on the hackIT event for continuous improvement and growth. I agreed with them (and was very proud that we think that way). Plus it allowed me to dust off some of the dust from my skills as an agile coach and facilitate.

We reflected on the event. It was a success overall to the group and they saw the value and hoped we make it a regularly reflection of our culture. I committed to them to ensure that I championed this event to my partners in leadership (who were impressed by the event as well). Here were the things we centered on for improvement:

Start Doing

  1. Preparing technical needs (server VM provisions/configurations) earlier. We had some unique needs that caused difficult for operational team members to be a part of the team for dealing with configuration needs.
  2. Being more widely inclusive. I took the blame for this as I have spent a significant amount of time and energy on cultural building and team building and because I knew we had really moved forward here, I was uncertain if the organization as a whole was ready to be able to participate in this type of event. In retrospect, it was probably fear and uncertainty that drove this as I wanted to show the value and so I tried to keep it like a small experiment. But as I found out, once the genie is out of the bottle and coupled with not managing the message to the outside, it can cause more problems than necessary due to lack of understanding.
  3. Re-thinking team size guidelines. We also had allowed teams to be of any size (including a single person). This resulted in at least one team forming into the event as they had not joined another team and needed help when everyone was focused. Having a team of one sounds good in theory but in practice it goes against our more communal cultural core values so we may have to change this approach.
  4. Changing the voting process. We had kept voting simple for this attempt by creating paper votes with team names and a box to mark ‘X’ by the selected team product. The problem that happened was that two teams decided to build a product that was pretty coupled in how it was thought of (resulting in a tie for the teams as people voted for both consistently). A suggestion was to use “chip voting” to allow people to vote for multiple products.
  5. Earlier clarity of ideas prior to kickoff. What we noticed as a lot of teams kept ideas “close to the vest” as opposed of getting them to an idea board (maybe to be strategic). Getting those ideas out there earlier would allow people to create more diverse teams and allow people to know if they wanted to try and create their own team or join another.
  6. Display our countdown clock in a central location. We had a countdown clock on the home page for the event of the server hosting the products. It was never looked at as folks were too busy. Was it even needed since we defined the timeframe? Food for thought.
  7. More planning. This actually arose from an admin we pulled in late to coordinate a lot of the activities (mostly based on an unknown budget). We actually started the work about 6 months before the event but the swag and food was all very last minute. Fair assessment. We can do better.

Stop Doing

  1. Eliminate the need for use of VPN. Based on the enterprise network configuration, utilization of wireless requires the use of a VPN client. This caused some issues in demos as they tend to timeout, etc. Not sure we can eliminate it but perhaps we can be better prepared to deal with those issues.
  2. The Drama! This stemmed around my approach to “keep it small” and lack of wider communication until the event was at hand. I’ll handle this much better next time.
  3. Less Snacks (I ate too much)! We provided breakfast for the organization day one, lunch for teams day 2 and then lunch on demo day for the organization. In the afternoon, I pushed a cart of snacks and treats around the floor across the entire organization to make connections, allow people to take a break and share a conversation and give them a nice treat. Apparently some folks felt the temptation by my cart of treats was more than they could stand. Overall it was a good thing but leads me to consider how to make it more balanced and healthy. I’ll think this through to create a more balanced mix over the week.
  4. Plan the schedule and work the plan. We were in the midst of wrapping up some hiring paperwork and so on the day of the event, my kickoff instructions may have not been as clear as I wanted so I had to do a follow-up. I had the scheduled outlined in the initial presentation I did with the teams. Next time, I will rely on visual aids if I have them.
  5. Stop spending so much money (this was directed towards me). For the most part, I funded this event from my own pocket (and I will not share the amount). I never actively solicited for reimbursement from anyone as I felt it was a personal passion and I wanted to do it (thank you to those that contributed though as every bit helped). I made sure everyone in the organization had a t-shirt for the event, bought snacks for the week, provided organization wide breakfast and lunch and team lunch and some other items. I told my teams that I saw this as an experiment and wanted to demonstrate how to support it and as it was a passion for me, I funded and did not regret spending a single penny and would do so again if necessary as I believed in it even more after it was done. But I did agree to be better to solicit for funding next time.
  6. Taking about every detail or trying to make things perfect. Some of the more junior members of the teams struggled with the idea of not going into deeper discussion or trying to perfect the products. This was impractical given the timeframe and created stress for them. Fortunately our more senior developers were there to guide them as to making decisions as to what could and could not be done within the timeframe. This is a skill that gets learned as we do this more. What can I actually build in this timeframe? Product ideas developed are potentials for future products but should be seen as R&D, not as production ready releases.

Conclusion

This experiment with hackIT turned out to be a great success and something I think I can see us further developing into our culture supporting core value beliefs we have in continuous learning and growth and the power in experimentation without the fear of failure. As for me, it was a personal joy to see what an amazing group I have to lead everyday have the way we believe and the talents they have be shared to the wider organization.

I leave with this …

“When it comes to innovation, an ounce of execution is worth more than a ton of theory”¬† ¬† ¬† ¬† ¬† ¬† ¬† ¬† -Phil McKinney, former CTO of HP Personal Systems Group¬†