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



How can I be Agile?

“The ones that are crazy enough to think they can change the world are the ones that do.” – Albert Einstein

My organization is changing and adapting. As a leader, I am being purposeful to make this happen. I have brought in 2 managers to focus on the “day to day operations” and to continue to perpetuate both our technical and cultural growth. This has allowed me to start thinking with much more depth and breadth about the organization while ensuring that the culture that has been built continues to receive the appropriate level of care and feeding so it can be nurtured to continue to grow. Many were shocked that I did not do this sooner but, again, as a leader, I wanted everyone from the most junior level employee to the most senior level employee to initially have no obstacles directly to me. This also meant based on the levels of time approvals, performance reviews and personal coaching that I was instilling into the culture the ability to be self-organizing and self-managing. It created a “top down” support culture as opposed to a “top down” decision culture. In doing this, I think the balance has been found very well inside the culture where people feel the autonomy of teams to make good decisions and accept the responsibility of those decisions.

My colleague (amazingly customer service oriented), who handles all of the operational aspects of the business has been trying to help his group find a balance of agility in how they operate. He does not have any real champions today who “get agility” and based on the needs of the culture in place (as operations is much more enriched in a process and procedure approach than a looser framework) they understand the need but have difficulty applying it to the work. I am hoping to be able to assist them in finding the balance for themselves.

The Context of Work

Early on, I really struggled with the idea that the operational group could not adapt to becoming more agile in their approaches. I almost felt that they were not even being open to it. They went to classes, etc but never seemed to embrace it. Then I finally got it. Leadership had been asking them to “become more agile” without ensuring (or assisting) that they even knew what that meant or even where to start.

The funny thing is that this realization really hit home with me when looking for some Sriracha sauce in my refrigerator. I looked into the fridge and couldn’t see it so, as I am want to do, I asked my wife where it was. She said it was right in the door to which I replied; “where? I can’t find it”. This usually results in her coming over and pointing out the bottle right in front of my face. To which I often say “if it were a snake it would have bitten me”. It was right in front of me, I knew what I wanted yet somehow I could not secure it. This made me think about the teams and what they really may think about what “being more agile” really meant. Maybe it was right in front of their face and they just needed someone to point it out to them (like my wife was kind enough to do for me).

I also realized that perhaps why they were struggling was based on the context of the work they do itself. I believe that it was Stephen Covey who talked about trying to find rocks and ask “is this it” when taking a moment to ask what kind of rock you needed may have made this task more efficient. So, I was guessing that they understood the concepts and goals but applying it to a work context that was less about creativity and more about consistency seemed like scaling Mt. Everest.

Eating the Elephant One Bite at a Time

Often times, our leadership team uses this phrase to talk about the decomposition of work. It has always seem to convey a universal understanding with us that it is easy to become overwhelmed by something too big but if decomposed into bite size pieces, it becomes more consumable. So, this is what I suspect I can use to approach this goal of operational agility.

When I first started, the deployment of software in my organization was a heavily document driven process with staging server folders and handoffs and low communication and high mistrust between development, operations and database that someone would do something that they should not do. So, in response to this; things were locked down in certain levels only to be touched by a master craftsman. This high speciality of skills meant that deployment became very dependent on 1-2 people with the knowledge and skills to deploy code to the production servers. This always struck me as a really bad plan. So this was one of the things I tackled first.

My first goal was to understand the concerns and needs of the involved groups.

Development wanted to get code to the stakeholder as quickly as possible and not have at to jump through hoops to have small changes made. (They wanted to control the development environment so they could be responsive).

Operations wanted consistency among server environments and guidance in what was needed to be changed in the environment to ensure that the changes did not create a supportability issue. They did not want people making server level changes without being involved. And they wanted documentation that clearly outlined the steps for deployment, the dependencies, etc.

Database was less complex. They wanted to to know if there was a precedence of order for their work in the deployment. Since they personally ran all database scripts, they would check them and ensure that they did not have a negative environmental impact.

So all of the needs and concerns were pretty much on the table to address. However, the idea of moving from a manual process to one of full automation was a large task (an elephant).

So, we started with asking operations to sit with development and if we did a build and deploy to the server share, what details would they need at that point. This allowed us to automated the code delivery mechanism and only leave manual the server deployment. Over time, we were able to work with operations to secure and work together to stand up a deployment server tool that would allow them to review the deployment, secure product owner approval via a workflow and then deploy the code and restart services at the push of a button (removing the expert dependency).

Taking this “one step at a time” approach helped us achieve higher agility and facilitated communication on both sides of the process to ensure we fully understood the needs that each group had and find a balance. Does that mean it’s done? Not by a long shot. We still have room to raise the bar but by using the core tenants of inspection and adaptation, we can retrospect on how the process works and further improve. As Mike Cohn is quoted to say “agility is not something you become, it is something you become more of” …

So what does this mean in my work context?

What this boils down to is often people focus to become textbook agile. They think it’s an application of process and procedure but they leave it devoid of the cultural shift. Take a moment (I often say this as I feel often we “do” but never take that necessary time to assess) and assess the pain points of a situation in terms of the agile principles and ask yourself the following questions:

  • How could this situation become improved through the increase in individuals and interactions? Are we relying on processes and tools as this mechanism to meet the need today? Often times taking away that face to face interaction loses the overall understanding of the need (ever had an argument over a text message thread?).
  • Are we “end goal focused” in terms of meeting the need in terms of the value of the solution?  Or are we in a “cover your ass-sets” mode that is overloaded to ensure people do not do the wrong thing? Have we allowed a historically bad situation to shape our overall approach?
  • Are we focused on collaboration as the primary way of working to create a solution and shared understanding? Have we developed a culture that is more focused on an end document than the quality of the solution? If we are using a document as a point of shared understanding, do we review it regularly to ensure that it continues to create that understanding and adjusts as needed?
  • Do we embrace the overall concept of change? Have we created mechanisms that attempt to stall or avoid change for the sake of being consistent? As painful as change is, it is a given. Things always shift.
  • Are we using fear as the driving mechanism for what we are trying to accomplish? Has our outlook been colored by a previously bad situation in which a given process was implemented in reaction to this. Any process that has been created in an attempt to ensure that “this will never happen again” is probably open to scrutiny. Given too many rigid constraints, people will work twice as hard to find ways to work around them through informal channels, relationship building and holes not yet discovered. Be open, honest and trustful to the end value and the people performing the action. Bad situations typically arise from lack of knowledge, general mistakes or incompetence. Those are all things that can be remedied. I have rarely found a situation in which someone intentionally set out to do something malicious in terms of the general process of work.


 So why did I take the time to think out loud about this?

This topic came to me as I have seen more and more people struggling with how to be “agile” in their approaches, especially when it comes outside of the context of software development (which has a lot of frameworks for guidance). I have seen managers try and apply kanban and lean and scrum in other functional work contexts without starting with the basic ideas of defining how they work, what the workflow is and with a lack of understanding to the underlying principles of agility.

Take a moment to read the agile manifesto and see how the meaning can be adjusted to better fit your work context, determine a purpose and end value proposition to the things you are striving to do and look at how you are working with wide open eyes. Include people, ask questions, understand needs of the end result and inspect and adapt within a regular horizon. Keep in mind that the cultural installation of agility allows you to adapt any process when things breakdown or in the face of shifting priorities, circumstances or needs.

Have a great week everyone and stay agile!







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.


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!

Baking in Quality

“Quality is everyone’s responsibility” – W. Edwards Deming

Being someone who started their software career in the field of testing and later moved on to lead groups to implement automation within testing groups, I have a strong belief in the value of tested software. That being said, as we have shifted into the world of agility, the idea of “tossing features” over the wall is an antiquated and less productive way of thinking. Software testers, QA or whatever you want to call that domain do NOT assure software quality in isolation. I have been thinking a lot about this lately as we are examining test automation and it has been primarily at a GUI perspective and it makes me wonder if we are fascinated with the tools or actually have a solid test strategy.

When I began my journey towards becoming more agile, I came across a phrase very early on that has stuck with me and helped not only shape my ideas of software quality but also discard some of my previous teaching as a quality domain professional. The phrase is the title of this blog post … “baking in quality”.

I suppose this resonated with me initially based on the bad experiences that all testers face in their career where they are provided features late, largely untested and often in compromised product  schedules.The idea that as a team we would ensure quality appealed to me as it made it a shared responsibility of the team as a whole and not the sole domain of the angry tester telling the developers why their code is full of bugs.

In direct response to this when I began building software teams, I routinely asked the question “how many testers are on this team”? Commonly, I got the answer that only counted the people that had expertise in the testing domain. To which my reply was always, “I see N number of testers” (replace N with the total team number). It took a while but the phrase “everyone is a tester” is something I hear routinely although I do not think it is at maximum effectiveness just yet.

Adding the Right Measure of Ingredients

Mike Cohn in his book “Succeeding with Agile” talks a lot about the idea of testing and how automation is critical to the testing process as teams mature and become more effective. Almost every new team starts out with manual testing of some sort and the pains of this practice show very soon when the teams start hitting a consistent cadence. Without good quality practices many teams, including my own teams, begin emulating a “mini waterfall” method in which test domain experts spend a great deal of time front-loading manual test scripts and being delivered features late in the sprint in which they scramble to get “tested”. Even with the “everyone is a tester” belief ,the primary test expert is often overwhelmed by the wall of days of code development and scrambles to meet the commitments made by the team. Most testers are used to this “stuff rolls down hill” scenario and are often powerless to avoid it. But I think there is a better way to “bake in” the overall quality of a product. Will it be easy? For some, maybe as they are well on there way bt for others it will be a large hill to climb. The great thing about being truly agile is we evaluate small experiments and adapt and adjust as we learn.

Mike Cohn and Martin Fowler both talk about the testing pyramid. If you are well read in quality techniques or have a lot of experience in the test domain, you have likely heard this term. The traditional way I was taught to incorporate this philosophy into testing looked something like this:


This stemmed from the idea that testing at the user interaction level would yield the best results in terms of finding problems. This approach was a standard for a long time in many gated project methodologies. I made a career pivot in teaching others how to effectively use testing tools, many of which are targeted at the E2E (end to end) GUI level, to build scripts to do this. But given we are developing the system in an iterative fashion these days, this diagram no longer makes sense. (oh my shattered innocence)

Cohn and Fowler talk about the inversion of the pyramid focus in terms of agile development so that it looks something like this:


Part of the realization behind this is that with the system being iteratively built, the volatility of the interface (and therefore the GUI script fragility) can be slow and costly to refactor in the midst of building new features. Many teams work to mitigate this through adding a specialized role to focus on test automation, but this is again an increase in cost (as it adds a speciality person to the team) and promotes a decrease of team ownership of the quality of the product through relinquishing this responsibility to “the automation dude”. Some create a shared service that works across teams to take on this responsibility and typically the expanded scope of this person means they need to maintain multi product and possibly platform understanding and therefore defects may come later into the mix once the scripts are shored up. These folks are almost always focused on E2E regression tests and do to their spread scope, they are often just churning out scripts with little quality oversight to their own work. So this is where Cohn and Fowler flip the approach towards a “baking in quality” approach but one that uses significantly more code level testing and less GUI level E2E testing.

Their assertion is that if we are maintaining a solid base of unit tests (maybe even couple with gated code checkins) and upon that building what they call a strong “service” level of tests, which they define as “the points in which the application responds based on a set of input or inputs” that a large degree of code that is small, fast and repeatable is available to exercise the system regularly. This also alleviates working on redundant GUI level tests for validations and the focus can be for more “user journey/smoke tests/happy path” tests for E2E. This means that tests can be adjusted as a part of the overall code base for the most part and that the focused efforts of GUI level testing can be more targeted to perform an overall goal action.

So, what does this mean in practice?

It primarily means that if we want to make a shift towards “baking in quality” our strategy might be to focus on building in quality as we construct as opposed to trying to post build or bring in specialized people whom we entrust to build in this quality. It means that if we think that the quality of our products are important that we build in this discipline to how we work as a whole, not as a sub-process. It means we internalize the concept that “baking in quality” in how we build products, is what we do as a culture.

Before all of the automated tool vendors gather their armies and seek me out (as I have used a lot of these tools and like a lot of them), I do see a tremendous amount of value in both commercial and open source testing tools and frameworks. The thing I do see is the same thing I saw when I was brought into companies to help them with automated tests; either their testing practices were weak or they were amazed by a sales demo and were ready to automate everything based on the sales pitch, which always worked, in the hands of experts and in controlled environments, flawlessly.

But as I am often noted to say, “I think we may have our emphasis on the wrong syllable”. Maybe we should be doing as these agile pioneers suggest and working towards baking in this quality through solid coding practices as a complement to effective use of automated e2e GUI level testing. Maybe we’ll bake in more quality as a whole within our products.

I have spoken to a great deal of testers who have told me all of the amazing things that their automated GUI scripts have found in terms of defects and monies saved. I get it. GUI testing of systems has value. I agree. As a matter of fact I whole-heartedly agree, especially when it comes to becoming even more “dev-opsy” and you can provide operational deployment scripts which run smoke tests so that they can execute them as needed and feel confident about a deploy. So, don’t shoot the messenger here.

However, I do also believe that effective use of code level testing + guerilla and manual testing + GUI regression and smoke tests might be an effective recipe as well. Some of this can be supported with the challenge I put forth in my last blog post ( Just one thing … ) recently.

And will it slow down a team initially? Likely. But I think it can be accepted and will pay dividends in terms of more quality produced code and products overall in which extensions can be tested to effective ensure less “breakage” across a sea of code. And I believe once the practice becomes ingrained, the velocity of delivery will become consistent. It also allows you a terrific pairing mode opportunity for new hires to learn about code under construction.

So as usual, I am up to run an experiment to see if this works and bakes in more quality in products effectively. Are you? Have you already done this?

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”?


Customer Service

“You are serving a customer, not a life sentence. Learn how to enjoy your work.”                      – Laurie McIntosh

This weekend I had to run some errands and I arrived at a local business just as they were opening to pickup a delivery. I stopped at the drive up window, rang the bell and patiently waited. A clerk came rushing in sat her items down and opened the window … “Name”, she asked sharply to which I provided her my name. She fumbled around and said in a tone as if a burden were being placed upon her “We just opened. It will be at least 30-45 minutes”. I thanked her and said I would return in about an hour. She closed the window and walked away.

As I drove to another place where I could occupy an hour (as returning home and then coming back would be pointless due to the drive) I began to think about customer service. Not about this particular incident specifically but what “customer service” really means. Customer service is defined on the interwebs as “the assistance and advice provided by a company to those people who buy or use its products or services.

This being the case, on face value, this woman provided customer service as she indicated how long I should expect before my delivery was prepared, correct? Sure, she absolutely met the definition of “assistance and advice”. But did she delivery it in a way that made me happy to be a customer? I would say not. Her rush into work and exacerbation from that experience translated to how she provided that customer service. I get that we are all human and are affected by life’s experiences but sometimes in the service of others we have to rise above all that. Easy to do, no. But something we should think about in terms of customer service.

The reason I began thinking of this as it made me reflect on a story I had read about Zappos and its early beginnings. One of the values that Tony Hsieh strives to instill in each and every employee is the ideal of amazing customer service as the experience from that places an imprint on people that make them want to return and do business again.

When his company was first starting out, he was courting  all of the major shoe manufacturers to stock his warehouse (as they learned that controlling the shipping timelines was another way to maintain a good customer experience) with their brands so he could provided diversity and brand loyalty names. On one particular case, he had been out for dinner and a lot of drinks with a particular rep from a company and they returned to the hotel at the early hours of the morning. Tony had spent the night selling the representative of this manufacturer on the core customer focus that Zappos had and how their superior customer service. The representative, probably a bit tipsy, told Tony that he wanted to see how “customer focused” his staff really were and if they were as he said, he had their account. Tony agreed to take that gamble.

The representative called Zappos, again in the wee hours of the morning, and got through to a customer service representative. The call center responder answered with zeal and said “This is Zappos, how may I help you”? The shoe representative said; “yes, I would like to order a pepperoni pizza please” in a tone of seriousness, fully expecting the call center to become angered and explain to him :”that is not what we do here sir”.

Instead, the call center representative said in a pleasant tone, “may I have your location sir”? The shoe manufacturer provided it to which the call representative stated “please hold one moment, sir”. The shoe manufacturer waited a moment and the call center came back on the line. “Sir, I apologize that we are unable to meet your need directly, however, based on the location you have provided to me, I have a list of local pizza shops that I can provide to you, the closest being open until 4 a.m. Is there any other way I can assist you sir?” Flabbergasted, the  shoe representative took the number and thanks the call center representative. The call center representative closed the call by thanking the customer for their call.

Over a late night pizza, the shoe manufacturer gave Zappos their business.

This may be an urban legend, but it makes for a good story for sure it demonstrates to me what customer service really entails. The call center representative adapted to situation. They did not become frustrated because some intoxicated person called wanting to order a pizza, clearly not what they did. Instead, they used the situation to continue to provide excellent customer service and potentially establish a customer for tomorrow.

Isn’t that the core of customer service? Our goal is to “help the customer”. This is something that we cannot always do directly but if we go back to the definition of customer service as “the assistance and advice” this means that sometimes we help them by providing them with a direction, not a solution. We have to be willing to maintain that focus to help assist and advise even if out of scope. Does it take more time, sure. Does it mean we may have to try and find information that they could have found for themselves, absolutely. But being focused on customer service means you are there to guide that customer to solve that problem through your direct action or by helping them get a point of direction to that solution if at all possible.

So, coming back to my experience; did the lady provide customer service? Of course she did. She told me when I should return and my order would be ready. And when I returned, it was ready. I thanked her and went on my way.

Could she have left her frustration for being late for work out of the context of her customer interaction with me? Maybe. But that is an area for personal growth for her, not the basis upon which I judged if she provided the end customer service. I weighed this against the outcome. Her brief frustration did not make it a situation where I felt as though I received bad customer service. She was rushed from being late to work. It happens and as a result if we are faced with an immediate interaction, I cannot say that I would have handled it any better.

Are you “advising and assisting your customers” or just merely dealing with them?