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!

Observations and Adjustments

‚ÄúOne must learn by doing the thing, for though you think you know it-you have no certainty, until you try.‚ÄĚ –¬†Sophocles

I always thought this was an interesting quote. You cannot gain any certainty without trying … something. And even at that, you may actually fail. But if you are truly learning, you adapt and adjust and give the next experiment a fair shake of success.

From software to science, using experiential learning as a way to define an experiment, to conduct and observe the outcome to potentially learn and adapt the experiment as needed has created amazing products and scientific breakthroughs.  It works. I think we can all agree on this.

So, why do you think we don’t apply it to something like organizations?

Fear of Failure

Thomas Edison is quoted to have said “I have not failed, I have just found 100,000 ways it will not work” in relation to his research into the first lightbulb. This is a very healthy way to look at progress but very contrary to a lot of business thought. Why do you think that is? My speculation, which could be very wrong, is that for Edison there was the possibility of the realization of a dream forged from that creative spark with future potential of a product. For many businesses, the future capital earnings heavily outweigh the creation of “the thing”. Many of the successes in the world have been born from the want to capture an idea and then only become monetized later therefore reducing the fear that capital is burnt without return.

Often times, creators of these eureka products (Google and Facebook as a couple of examples) are often shaken by the idea of monetization as the creation was the core driving factor, not the end profit result.

I honestly feel that the initial introduction of the drive to capital gain often induces this fear and it creates a trickle down effect from the very top all the way to the source of creation of the product. The pressure to get to market first and capitalize of the highest money stream may cause people to become less innovative, take less risks and instill a fear of product failure even before it hits the waters.

But I contend that keeping the horizon for learning at a “just enough” level not only helps you determine a better product but it can save money from building out full features that are often unused (see the pareto principle as applied to software features) or poorly received.

Minimal Viable Product

Eric Ries of the Lean Startup approach introduced this concept (I think it had rolled around for sometime but he is connected with the idea) as producing the smallest amount of the idea to learn from. Basically a seed of a product to gauge a posture to “pivot or persevere”.

One of the most noted examples of this approach is Dropbox. The initial MVP for this product was a marketing video explaining the product and how it would work. This was launched and an accompanying form was created so that potential customers could sign-up for future information about the product or provide feedback.

This allowed them to gauge interest to know if their investment into the product in which they saw high potential value showed a reaction by their potential market. This was actually one of the most brilliant approaches I had ever seen. They were actively working on the product and seeded their base features before completion to test the market space. Had they gotten a less than exciting response, they could have targeted marketing research and determined why or pivoted their approach in some way (either the campaign or the product work).

How did this help them in proceeding this way? It allowed them to learn about the interest of their potential market and gauge feedback from customers before launch so they could consider the feedback and potentially pivot with the market. If the feedback was a “lame duck” they could have abandoned the product altogether and pivoted towards a new direction. This allowed them the potential of failure much earlier. The potential magic of all product management after this stage is having that gut feel for how long you can ride this curiosity until the product must get to market. This is why really good product owners stand out.

Minimal Marketable (or Lovable) product

This is another concept introduced that we see extremely frequently in the market space of software and software services. Determining only those core level services or features that get buy-in to a product for more. This means that product vision has to be solid to get these to market and feedback and seeding of new features is sought to be cadenced regularly.

The initial iPhone release is a prime example of this approach. When initially released, the iPhone lacked many features that were present in many of the competition in the marketspace (MMS messaging, apps and the ability to copy and paste). But when released it became one of the fastest selling phones in the cell phone market (competing more closely with mass volume sales of game stations like the Play Station 3). Which it did seed was a phone level OS with an SDK for developers to build upon (even though there was no store in place yet for deployment or sales mechanism). These “missing features” allowed them to gauge the market reaction as they had faith in their initial MMP to ensure the importance of future features and to allow them space to ensure that they released the best quality updates with these features sought by customers.

They released a product that seeded a way for it to grow (the iOS Phone SDK), made it available to the developer community and focused on those features of differentiation that allowed them to not only contend with the market but even under strong criticism and scrutiny release the features not initially there in a thoughtful way consistent to their brand and end goals. They essentially “hooked their customers” through thoughtful and innovative design and a stellar responsive interface (far better than competitors) which allowed them to build the features that would build a community around the product. By making the Phone OS available, they even made it possible to “jailbreak” the phone and create some of the missing features which could allow them to gauge what potential customers seemed to be drawn to use. This allowed them to strive to introduce the right features at the right time and draw from the community at large to create a learning opportunity and pivot as needed.

The Design Sprint

Another recent approach to the idea of validated product learning is the Google Ventures Design Sprint¬†. This idea distills the idea of rapid learning through a functioning (and often simulated) prototype to gauge immediate and rapid feedback from real potential customers for a idea over a short span of time. O’Relly Media has also written an excellent book on this approach which can be found here. The idea itself has been around for sometime and often attributed to be initially used at IDEO Design as early as 2009.

The idea divides the approach optimally into a 5 day approach which breaks down to one day focused on the following events:

  • Understand – Define and unpack the problem to solve (though interviews and research)
  • Diverge – Generation of ideas to solve the outlined problem (more is better, no wrong answers)
  • Converge – Determine which ideas or pieces of ideas will be pursued for testing
  • Prototype – Build a prototype of the solution that end users can actually play with and develop testing criteria to observe
  • Testing – Validate your assumptions through observation of user interaction with prototype and providing feedback

Here are a couple of real world examples of how this has been performed

Building a new Shopping Cart (IDEO, 2009)

Savioke – Building a Room Service Robot

This approach may not work for every scenario but as a tool in your toolbox for learning, this can be a rapid way to learn what resonates with your potential market and generate immediate feedback from real-world interaction.

So, where does that leave us?

In the vein of this blog being focused towards being about agile leadership, I wanted to explore this topic to hopefully inspire those leaders to truly see the value of a targeted small experiment from which you can gain quick knowledge about your potential product from which you can pivot, persevere or abandon. The key being that failure should always be an option but seen as a mechanism for learning and focus as opposed to use as something to vilify a bad approach.

I hope this will guide you to finding tools to help you target your search for knowledge or even better be inspired to create the next approach of which I blog about.

Fail fast and stay agile!

— Todd

 

Ownership vs. Visibility

“You don’t currently have permission to access this folder” – Microsoft Windows

I spent some time yesterday running a coaching exercise with a group of product owners to help them start utilizing a regular retrospective to reflect on improvement as an individual product owner and as a team. I knew it would be challenging as the engagement of thi role often spans across an entire organization so it could be easy to slip from “continual improvement” of self and team to that of complaint and focus on all the pieces to which they interact. In the end, I think they did a great job to start taking a moment to allow for some self-reflection.

One thing I did try and make visible as we worked through areas of “doing well”, “needs improvement” and “abandon” was to reinforce the idea of a separation between ownership and visibility. The reason I thought this was necessary is that the items of time management and focus were identified across the group. So I asked them (after letting some debate occur at times) as they identified issues (as to keep it focused on individual and team improvement) 1 simple question:

“Is this something you can control or fix or is this something you seek to make visible”?

That surprised a lot of them initially I think, as their role itself is aligned at a very high level within our organization and they sit with the people both within the business and IT that are responsible for organizational level change. So they had never really even considered not being part of that organizational conversation in the “how things get done” on a broader scale. Plus when we identified the responsibilities of the role, it was clear that they feel highly aligned to bigger strategic goals as they sit in the forefront of items they identified. But they took to the idea well and really allowed it to help guide them along as they consider what they identified.

But this had me considering something broader, the idea of ownership vs visibility itself and the positive and negative consequences of both aspects.

Lack of Control

I¬†don’t think that there is anyone that prefers to not control a situation and be subject to the end result. It’s not a comfortable feeling. For example, I know as a father that I have always struggled with the relationship and focus my daughter has with school. My viewpoint is that you need to take this seriously, work hard, make good grades so you can take advantage of this educational opportunity. So when she would tell me “I forgot to turn in an assignment” the dad lecture soon followed. But one day after sitting with my wife (who I often think helps me refocus) I realized, I cannot “own” her work or motivation. She has to attend the classes, she has to perform the work to the ability at which she is capable and she has to assume the responsibility to turn in the assignments. The control I have in this situation is ultimately limited. Sure, I was able to ground her for bad grades, take away privileges, etc but when it all boiled down to it, I could not go an “do” the work that she was being asked to do. I had more reactionary authority than prescriptive authority (or so I thought initially). What was definitely within my control was to make my expectations clear, indicate what would happen should she not meet them and follow through. So my span of control was to help her succeed which meant she and I had to ensure I had visibility to do so.

Can you see me now?

“What we need to do is “… How many people will catch themselves saying this today? I will if I pay enough attention. And then, how many things will we say that about in which we actually have no authority, input, responsibility or experience the consequences if it does not work out? Probably a lot of those “what we need to do” statements fall into this category. We all have opinions and often we all feel the comfort and the freedom to express them within a healthy organizational culture but what about when we express our opinion and hold onto it as more than an opinion? It’s input. We are helping you solve a problem, just listen to me! If we maintain this stance then we experience personal frustration when things do not unfold as we suggested or within our expectation of need. I’ve done it. And every single time I catch myself, I usually think “it’s really dumb for me to keep worrying about this as someone else has to implement it”.

What we are really seeking is visibility. I want you to know the pain point, the frustration, my idea, my suggestion. And that is fantastic. A culture that allows that open communication and transparency of thought is a fantastic place to be. But without separating it from the notion that other people may be responsible to make the decision and implement within the scope of a backlog of other items they have in place can end in personal frustration, lack of trust, a “time sink” of worry over the end result and a general idea that no one is listening. I get it. I have experienced it. I have felt this way too.

Emergency!

I used to work with a unix administrator who had a placard outside his office that read “Your emergency is not my priority”. I thought it was funny (and a little of a up yours type comment which amused me as a young tech). But as I worked beside him, I noticed that everyone that came to see him had a “critical issue”. I mean each and every issue was critical. And as I grew in the tech industry I realized that this often applied to features as well from stakeholders. I also observed it in my own life; why did I have to wait between 8-12 for the cable guy to arrive, did they not realize I needed my wireless network? Did they not hear me tell them that I worked in IT and needed service? Did they think this was providing good customer service.

I have grown quite a bit older and perhaps gained a bit more patience but even as recent as this weekend I had to catch myself and think “am I in control here of this outcome”? I recently went to a fast food restaurant drive up to get some dinner with my wife and the line was very long. Not only was the line long but we barely moved forward to get to the order area. I felt myself becoming frustrated based on the situation (and probably a need for some lunch). The longer I sat, the more frustrated I became. I began to ask myself questions in my head like:

  • “What is wrong with these people, do they not realize that we all are waiting to order”?
  • “They really should do something to be more efficient, this is ridiculous to wait this long”
  • “Are there enough people working today”?
  • “What is the problem here”?

But then like a weird sensation it hit me. You cannot control how rapidly they will serve you or how soon this line will move forward. You can control if you continue to sit and wait or choose something else for lunch. You can call the number on the door and make visible your bad experience. My span of control was to leave or move slowly forward and order the lunch I wanted and to make visible to the company my experience.

I had to let it go.  I had to allow the people responsible to solve how the restaurant was run address the problem. And, even more important, it might not be solved the next time I returned for lunch. I had to accept that. I had to embrace what my actual options could be and act on those and then allow myself to offload it to the owner of the solution.

My emergency of getting that lunch item was not their priority at the moment. I actually had no idea what might be impacting the delay in service. I could only speculate and complain about the experience, which actually did not solve anything. But I could make it visible so that someone who could solve it could do so.

You may be thinking about now, how does lunch frustrations and concerns about your daughter’s education translate to this idea in the broader context. These are just simple examples of where my initial thought of control created personal frustration, used up necessary time that I could have done something productive and allowed me to let my mind speculate on why the problem existed, offer potential solutions and not fully understanding where my span of control started and where it did not exist. These examples demonstrate how if I accepted the idea that I could make someone visible to the problem/need or expectation and extend trust of the people who owned the responsibility to solve it, I could be less frustrated, regain wasted time thinking I was solving everyone’s problems and focus on the actionable things I could do, like get a really good lunch at the end of a long wait and see my daughter turn her own grades around and attend her college graduation.

So today when you find yourself immediately thinking or saying “what we need to do is”, pause for a moment. Are you making visible a pain point/need/problem or improvement or are you mentally allowing yourself to assume ownership for this thing even if your span of control is the end result? Give yourself a moment to think about what you own and can solve yourself personally or within your team and make visible the items to others to give them ideas so that they can affect change. Be willing to be heard and allow someone to set priority and act. Communicate your need (sometimes we do have an emergency or time frame) but free up your own personal time and mental energy to solve everything. It led me to a really good hamburger and a college graduate at the end.

I’ll close with a quote I read this morning as I was thinking about this that seemed to frame this concept in a positive light: “When you let go you are creating space for something better”.

The cobbler’s children have no shoes.

“If we desert the inner self to focus on the energy outside, it leaves a vacancy inside”¬† ¬† ¬† ¬† ¬† ¬† ¬† – Trudy Vesotsky

There is a dilemma that every software group I have worked with¬†has faced and I have never seen anyone actually “solve it” in the grand sense¬†although I have seen some really good ideas in action. It’s the idea of investing back into the work you do as a software group so that you can leverage this investment in the ability to continue to “do the work” for others.

Hence the reason for my blog title. The cobbler does amazing work for all of the paying customers wanting to buy shoes but never finds the time to put shoes on his own children’s feet or teach them to be a cobbler themselves.

Where does this often stem from?

In my experience, this perpetuates inside an organization in several different ways:

  • Fear to apply capacity by the leadership for something in which direct end profit is not seen or justification seems hard to communicate upward to these leaders without technobabble.
  • Guilt, on the side of the workers, who feel like they will never be granted the ability to do this so they either complain or burn the candle at both ends to make it happen in shadows.
  • Lack of focus or understanding of need. As Stephen Covey talks about in his works, sometimes we are “too busy picking up rocks to as what kind of rock we are looking for”.
  • Sometimes it is just culturally engrained (which is the toughest). It is just generally accepted (and often with great grumbling) that anything without direct tangible end stakeholder benefit is just less important.

I remember when I was a young IT professional and I was sitting with an assistant director of the company who had tasked me to thoroughly understand how their IT organization worked and look at improvement opportunities.

I posed the question “I have observed that any project that is related to the business receives a budget, people and focus but I cannot find where the same approach is made when approaching upgrades of tools, servers or your technology stack and training, why is that”? There reply was immediate without hesitation, “those things are the cost of doing business and therefore below the line and as they are internal in nature are more flexible than customer delivery”.

I paused for a moment. “So, if they are the ‘COST’ of doing business, why are we paying for them on a revolving payment plan? What I mean is if the core goal and mission is to deliver modern and innovative solutions to end stakeholders, how can the justification of making the things upon which support your competitive advantage in the market be something that is¬†addressed in a “stop and start” manner to be superseded by other items without completion”?

And here it came … the death blow. “This is the way it’s always been. We cannot just take time to improve internally and not deliver things to the customer”. Discussion over.

I walked away from this discussion feeling really sad (and as a young professional, deflated and experiencing an early disillusionment) as this company had so many bright, excited people who were inspired to do the work they did. They wanted to do interesting things and support the business through bringing potentials of innovation. They were, instead, given the communication that we keep the factory running. We only think about making improvements when a production shutdown is going on. What this meant for them over time was they saw themselves get further and further behind and the climb to get current made the effort, the learning curve and possibly the investment so great that they would never receive the support they needed to make it happen. So, they grumbled, they left, or they resigned themselves to work with what they had to get the work done.

I tell this cautionary story as in reading it you may see similarities in the company you are in now. If you are and you are a leader in this organization. Affect change. Even the smallest changes you can do as seamlessly as possible to keep some cadence of improvement going. Don’t let the hill you pile up for yourself make it impossible to climb.

So what can we do about this?

Again, I do not have “the answer” as my organization struggles with this like others do. We have at least made a commitment to our culture and ourselves to keep visibility on this and push for these things without fear. Sometimes we win and sometimes we don’t.

Please do not misunderstand me in discussing this. I am not talking about the “junior level developer fascinated by every technology under the sun” sort of change. Not that you are in a constant pivot. But that if you are going to be in the business of software, you have to ensure that your tools and approach allows you to grow at a reasonable pace with the industry”.

You do not want to find yourself in a situation where the iPhone has been out for a decade telling your team, “we need to learn how to develop for mobile”. You might get there but it’s not likely that you are going to be competitive here. You probably missed your window. The same comes from jumping on tech early just to “get there” with no plan on ¬†cultivating the approach or refining the skills. I cannot tell you how many government agencies (and companies that contracted to them) I saw build a native iOS mobile or Android app just to see it wither on the vine, never get updated or enhanced and die on the vine. Mobile App storefronts are littered with these types of applications. They wanted to be “first” so they could take advantage early for the trend but in hiring out the work, they created a dependency on a end vendor to update this platform and typically at a premium, which often meant that unless the app was getting mass attention, slowly stopped being paid to update and support.

Those cautions aside, have some seasoned technology professionals (CTO, architects, senior developers) in your organization that watch technology trends and “sticking patterns” of languages. Understand your regional technology market so that you can hire for technology you can support more readily or develop a good “gig based economy” model for models that work in conjunction with teams you are training on a new technology. Don’t think you can ever stop learning and growing. And as a result of that, keep your toolsets as current as reasonably possible so that you are riding closer with software trends and not trying to just race to catch up.

If you are in the business of software, and this applies even if you are a software group within a non software company, cultivate and advocate to the business leaders as a whole being reasonable about the investment they make in technology as a core support of the business. Don’t be silent while budgets are drawn and plans are made and let the needs of the very thing you do not be heard. Be certain, the “cost” of doing business in building software is in fact a cost. Do not let it become something to do when there is time.

Get creative.

One thing we can try (and that we do here) is to adjust capacity of people to try and free up time for focus on doing these types of things. This can often be more palatable for a business. The idea of losing 2-3 people for 1-2 weeks to focus on this thing is something that “feels” reasonable on face value. It’s about the impact of a vacation by an employee. You will be amazed at what people who are motivated to leap, with some small pre familiarization, can get done when freed up to focus on a task. Just try and keep things small, targeted and end goal based. Even if the goal is research of a technology, have an end goal in mind like a “go/no go” and recommendations for investment.

Outline the tangible benefit for the effort. Think about what the investment will ultimately do for the business. And it does not have to be only about technology. Maybe it will allow you to recruit better in the market space, maybe it will allow you to retain staff as they continue to grow, maybe it is an early investment in the direction a given technology is headed. And sometimes, just sometimes; it’s to ensure the business does not make a large scale investment technically that it will be dependent on a recurring vendor cost to support, maintain and update or the marketspace indicates that leveraging of this technology is actually less effective than the vendor indicates. But stay focused to work on it. Don’t shelf work each time more work comes in. If you continue to do this two potential situations can result a) the ramp up time to get back to where you left off multiplies each time¬†you walk away or b) the direction you were headed becomes obsolete and therefore require starting over or abandoning the effort (which may not be costly but it does have a negative impact on those who have done the work).

Don’t let yourself keep building shoes for others and never attending to your own family.

Take a moment and pick one of these kids and build them some shoes!

Just one thing …

Curly: Do you know what the secret of life is? [holds up one finger] This.

Mitch: Your finger? Curly: One thing. Just one thing. You stick to that and the rest don’t mean s***.

Mitch: But, what is the “one thing?”

Curly: That’s what you have to find out.

Jack Palance and Billy Crystal¬† from the movie “City Slickers”

I always found this scene amusing when I was a kid. The old ranch hand trying to teach a city guy the value of focus for clarity. Of course at the time I just thought it was funny. After all these years, I realize that Curly was teaching a true agile value. Focus.

Focus is that thing that often gives us clarity. It gives us the ability to think deep thoughts and really unravel an idea. It allows us to extrapolate from a big thing into discrete pieces upon which we can undertake. It applies to things in life as much as it does in software development. I have started to really appreciate this as I prepare for an upcoming house declutter and move.

Do I allow myself to always embrace this seemingly simple approach. Nope. I, like others, allow myself to get too “focused” (and I use this term loosely here as it really not focused at all) on too many things. Like those performers that are spinning plates on a skinny stick, I find myself focusing on keeping them all spinning sometimes. But, as I am want to do, which often results in a blog post, I find myself stopping, breathing, thinking, assessing and questioning my current chartered course. So here we are.

Focus is a core value in agility as it allows us to actually be more productive by allowing ourselves to work to accomplish “that one thing” as Curly put it.

Under scrum, we demonstrate this through the user story, the task decomposition in terms of work effort. We use focus in terms of daily risk mitigation through a focus meeting called the  stand-up. We focus on the features committed within the review and the team within the retrospective. If you look closely, focus is woven throughout

Kanban has WIP and the innate concept of “pulled work” which itself a way to focus and measures this through the idea of how effective our focus on delivery is through things such as cycle time.

But there is one¬†dimension in which I often see less focus. In the process of delivery. What I mean by this is often I see scrum development teams use a “divide and conquer” approach in which teams members use their specialized skills to scatter and seek to deliver. They are in no way being less agile in this approach but I have always wondered what would happen if they allowed themselves to focus and iterate just like the larger product. There are examples of this. Just take a look at Woody Zuill’s mob programming or pair programming as outlined in Exteme Programming by Kent Beck.

My latest read, “Joy, Inc” talks about the use of pair programming as the standard way of how they hire and how they work. They see it as not only a way to create shared knowledge by this but also to ultimately be more productive.

So, I have posed this question many times to developers and often get the same response “well, development doesn’t quite work that way” to which I often reply “are you willing to try an experiment and either fail or be wrong”? *smiles*

My logic has always been that if a sprint backlog is supposedly composed of a top to bottom prioritized list of the highest business value, wouldn’t we want to work through the items (given we identify any dependencies and work to minimize those with the product owner) and focus to deliver each story in that manner during a sprint? Or even look at the absolute most complex item and focus on completion of that story and then work on the lower hanging less dense fruit?

I see 4 potentially significant benefits that could result from this:

  1. We get items in front of our team members specialized in quality quickly so they can assess features for compliance to acceptance, note any software issues or quality enhancements and they can become productive more quickly. They are reviewing and testing completed features, even if there are mocks behind some dependent needs of other stories. They also are able to learn a portion of the system under construction and build automation against it for regression more quickly if needed.
  2. If we for some unforeseen reason we are impacted to effectively deliver on all stories for our commitment, we can at the first responsible moment, assess remaining team bandwidth, current deliverable dependencies and make decisions so that we can have that conversation immediately with our product owner so we can remain transparent on the impediment and impact but emphasize our focus on the highest priorities or largest complexity first.
  3. We reinforce iterative development at the lowest level of development (by using refactoring and integration as part of the way we work) and can focus on ensuring that we meet our agreed definitions of done at each story level.
  4. We “should” end up with a set of features tested early which should allow us to as a team to swarm baking in quality for our product and preparing for our review¬†at sprint’s end (given we did not over commit …)

So in my view this approach makes sense to me and I have worked on teams that worked this way and we remained productive and felt like we were accomplishing more towards our product goals. We effectively delivered features regularly for review for the stakeholders.

A lot of folks may be reading this and joining the chorus of previous conversations saying “yeah, sounds good but you don’t really understand” …

So I reply to you all … “are you willing to try an experiment and either fail or be wrong”?

 

Recommended Read

“If you’re comfortable with the amount of freedom you have given your employees, you probably have not gone far enough”. – Lazlo Bock (Work Rules!)

I recently completed the audiobook of “Work Rules!” by Laszlo Bock (I went back a read passages I really wanted to dig into in the paperback as well). For those of you who are unfamiliar, Laszlo Bock is the Senior Vice President of People Operations for Google. He shares a very interesting insight into how they apply programs, policy and practices that impact employees and surprisingly how much data they collect to understand if they are actually making any real impact to the employees or the culture at large.

Some of the mystery about what/how and why Google does some of the things they do were outlined in the book. A few of them were:

  • Many of the services (like the haircut bus) provided to Googlers are at no cost to the company. It is often a brokerage between people operations and businesses for them to generate business buzz and customers. Many of things are often out of pocket for employees but adds a convenience factor for them to not have to schedule time to go and do these things.
  • The “micro kitchens” famously known at Google that allow googlers to grab a snack, a coffee, water, etc are actually spaced throughout the campus with intention to stimulate “unplanned interactions” where people from groups that might not directly work together might interact or spark and idea in one another.
  • Google has a performance management process and it gets scrutinized for effectiveness and adapted to bring the most value.

There are some really interesting ideas in this book. Not all of them are applicable to every organization but the underlying message is. If we have people focused on the operations of people and people are our greatest company investment, where is the downside?

The spirit of this book will hopefully inspire you to just think differently about how you can impact your culture in small ways and use data to determine if the “perks” you are providing are doing what you intended. I was so inspired by this book that I bought an extra copy so I could share some of this with our human resources, who are progressive thinkers as well.

I would highly recommend this book if you are leading a team, transforming an organization or maybe are part of people operations in your own company.  It will definitely inspire you to think about what things that you might be able to do to enhance the work environment and how you determine if it is working.

Stay Agile! ūüėÄ

 

 

 

 

 

 

Being Genuine

“You need to believe in yourself and what you do. Be tenacious and genuine.”

– Christian Louboutin

Genuine. Authentic. Real.

I think about these words a lot. I continuously question myself if I believe what I believe or do I just do what I do. Sounds like a lack of faith and maybe it is. I can exude real confidence in ideas I believe in as ideas are often very meaningful to me and my life.

I love to think, discuss, brainstorm, pontificate, learn, grow, teach, coach and collaborate. So ideas hold a real tangible value for me. But often times, as I awake in the morning or make my drive home in the evening, I stop to question myself as to what my true beliefs might be and if the allure of the idea has me thinking I “think” that way.

You may wonder why so I’ll tell you.

One thing, if I had to identify that thing, that makes my blood boil or loses my respect is people who talk about doing something a certain way or following a certain path and then abandon all those things central to that in reality of what they do.

They “talk the talk” but are unwilling to “walk the walk”. The reason I question myself is that I believe in agility, the power of teams and the ideal that amazing things can happen through motivated, collaborative teams in which the economy of scale is end value and not time. This means something very special to me as I not only believe it, I have seen the power in it actually working.

However, being human, I am inherently fallible. My biases, my environment, my mood, history in general can all push me away from making decisions in alignment with these beliefs I hold. I realize that and always question what I know and what I am doing to ensure I am truly being genuine in my thoughts and my actions. And guess what, it’s a struggle. It’s a battle. You stay on the defense for this creepy crawly to come along and get you.

Just like the dieter who struggles to avoid Krispy Kreme donuts brought to the office, sometimes it takes will-power and the admittance of failure. But my realization of my ability to be wrong and my willingness to admit and learn when at fault keeps me going where I want to go at this point.

I am very fortunate presently to have one particular person that keep me honest that works in my group. They challenge me regularly about my thoughts and often make me examine things that might be uncomfortable to think about from a perspective of an observed flaw. They basically exercise the carte blanche that I extend to the people I work with to call me on my B.S.

But I truly respect and appreciate it, even if sometimes at the onset I may not be too  as often happy, feel annoyed at the challenge or just clouded from the value I am receiving from those conversations. What they do for me though, more than anything, is they force me to evaluate the perception of another about me and probe more deeply into myself to see if my actions are genuine and in alignment to my beliefs and values. This often helps me examine why I might be out of sync to my beliefs or presenting a poor perception of my intentions or actions.

In the grand scheme, I am respect and appreciate this relationship that I have with this colleague. One thing it does is allow me to gauge myself on my skills to actually listen to this feedback without feeling the need to respond. I know that this is a skill that¬†I need to continuously work on. If you have never done a “seatbelt meeting” (where you strap yourself in and just listen to the good, the bad or the ugly feedback without response or defense but simply¬†allow you to hear someone else’s perception) with someone, give it a shot. Not as easy as it sounds to do.

So take a moment and think about yourself and your actions. Are you being genuine?