The Code you Love to Hate

“No matter how hard the past, you can always begin again” – Buddha

In my work environment, we have a portfolio which consists of a large amount of older code bases for which the team members are responsible to support for the business. I have personally experienced in the past the difficulties of supporting a legacy (I’ll use that term here but actually believe any product that starts it’s lifecycle from stabilization becomes legacy) applications and see how it can be a struggle for team members that I lead today.

Older technologies, poor implementations, no real guidance or design patterns, etc. Sometimes it is a real mess. I recall one of my mentors in development relaying to me when I was learning early in my career that fixing a problem in legacy code is often like donning a pith helmet and traipsing through a dense jungle. At the time, some of things I encountered used to make me so angry at why a developer might do some of the things he did in the implementation and it often caused massive refactoring (with care) to make it more maintainable. But as I matured as a technical worker, I began to realize a few base things:

  1. The developer may have been unequal to the task put before him. He may have been asked to do something for which his skill level made him unequipped to actually do and he created this in the best and most logical way he saw fit to accomplish his job. Maybe that popular “off the shelf” program did not exist when it was built.
  2. I believe that no developer sets out with the approach “I am going to write the sible code I can create”.
  3. The tools and technologies (or the depth of knowledge of them) at his disposal may have not allowed him to understand some of the side effects of things done.
  4. Maybe they did not have any real code standards or design patterns under which they were expected to write code.
  5. Refactoring of code is a given. Any code that exists and extended is likely to need refactoring when changed. Nothing is perfect.
  6. Bugs exist in the world. There are no perfect systems and any complex system will likely have issues that are unaccounted.
  7. If deep dependencies are used (3rd party or other systems) it is likely the developer though in terms of the environment of the day, not that the code might outlive those dependencies or they might change before this code base did so.
  8. Even if it is “legacy code”, as the current developer or team doing that job today, you assume ownership.  You may not like the way it is written or find it difficult but the base fact is that you have taken on this code base as a part of your job.
  9. You are in control of refactoring and can, whenever possible, make things better for those who come after you.
  10. Instead of focusing on the negative aspects of the code base, why not (as a developer reminded me recently) utilize the boy scout motto and “leave it better than you found it”.

Actual Problems with older code bases

I know as a technical professional we all hate inheriting a messy or poorly designed code base. It really sucks to have to work on it, fix it and sometimes just keep it running as the technical world changes around it. I often describe some as neighborhoods in which I try and perform the least amount of interaction and then get out.

I also know that many organizations do not fully grasp the need of the “care and feeding” of code bases or the deeper understanding that software should have a lifecycle and die and be reborn or transformed. Many organizations I have been a part of would rather hear the “thump, thump, thump” of the old reliable software and not think about what happens if it becomes in a critical state.

“If it ain’t broke, don’t fix it” is a very common idea. I actually knew a major software company that ran it’s accounting and payroll from a mainframe Cobol code base long past it’s prime and even hired high dollar consultants long term to ensure it kept running each time it sputtered and dropped a dump in hexadecimal code.

But the cost of continuing to gamble on these large complex systems is risk and if understood by the organization, they would see the importance to mitigate that risk as they would any other risk to the business.

It’s like driving a 1965 Chevy Bel-Air car. As time goes by, maintenance becomes more pervasive, parts become more difficult to find and eventually you may not even be able to get them or need to have them custom machined to keep your car running. This car may be something you keep covered in the garage and drive only on Sundays when the weather is nice. But if like a core business system, you used this classic car for your daily commute, the expense of upkeep and the risk of failure become greater and greater as time wears on.

So what do I do? I am a little scared now …

You basically have 2 core options:

  1. Bite the bullet and replace the system in total or find a way to “cage and lifecycle”
  2. Use a legacy transition pattern to migrate the system to a more maintainable code base in the future.
  3. Cross your fingers and hope for the best.

Option #1

Replacing a large complex core organizational code base is expensive. It is a large scale investment by a company and may require a significant technical  and personnel investment to replace. This is a fact.

But, just like buying a home, it is also an investment that hopefully returns greater end results through actually taking time to ensure that the system still actually supports the business and does not have “dead zones” of features that people cared about or wanted 20 years ago but no longer need. It gives you an opportunity to think about how a system models to the current business. And even while recreating the system, you still must maintain the current system and managing the changes to that system can be a challenge.

You also could encounter the dreaded problem of “thinking in the old system” as opposed to thinking in terms of how the business works. This can be especially true when a system has been a core system. People stop thinking about what the business needs and relate it to more of what they currently have to maintain in the system . This can be especially risky in disaster recovery scenarios in which the business must know how to function without a system being in place. For many businesses, they never consider this issue (given the world of distributed servers and cold site switchover).

In short, if you take this route, the organization has to be focused and it may be painful but the goal is to create something (hopefully in a better designed way) that can be cared for over time and change over time. If you take this route, placing a lifecycle for the system is probably important as well.

Option #2

One pattern I have become very interested in comes from Martin Fowler. It is called the “Strangler Pattern“. I find this approach very interesting as it balances the replacement of the former system with the new system but utilizes a common set of services to supply both until the legacy system is “strangled out”. The idea coming from vine growth in Fig trees that Fowler and his wife learned about on vacation. The vines sprout in the top portions of the tree and grow and eventually take over and replace the host.

I am not deeply versed on replacement patterns but my assumption is that this is only one of many. If you are fortunate enough to have an application that did use an MVC pattern, you might be able to begin to replace pieces in place and minimize disruption.

Another approach might be to leave the data structure as is (although legacy systems are often rife with business logic in the data tier), build the new system on an MVC or MVVM pattern with a services layer and later refactor the data tier over time and adjust the models to utilize the new data source while moving the business logic in a more desirable tier of the pattern.

Option #3

As surprising as it sounds, this is actually a path that some folks take. Please don’t find yourself in this situation as all of the hope and good karma in the world is not going to pull your backside out of the fire when (and I say this as opposed to “if”) things go South.

Final Thoughts

I started this post as I think it is important as team members that have legacy application to understand just as we collective own the new code we create, we own the code that came before us as part of what we do. I think that it is important for organizations to understand that these code bases can equate to risk and should be mitigated as any other potential impact to the business and that there are many ways that we as technical and creative people can help move the needle forward.

And most of all, the statement given to me by that developer on a team that said “leave it better than you found it“(the Boy Scout motto).

I think that is sound advice, no matter what you do in your organization and should drive us all …

 

Advertisements

Scrum master tips – The burndown

I have been working with several entry level scrum masters over the past few years and have discovered that although they may fully understand the general ideas of rituals and artifacts of the scrum framework, understanding the underlying agile value proposition these things support. Gaining insight into how they can utilize them with continued effectiveness with their teams seems to not be something that many do not often explore initially.

So I thought it might be helpful to convey how I view these items and how they can actually create impact for you as a scrum master to up your effectiveness with the teams.

My personal philosophy when I became a scrum master was that my role was a lynchpin in the process overall and that by increasing my understanding and effectiveness of the roles, rituals and artifacts, I could become a better servant-leader to a team overall.

This is merely how I view and utilize these things and hope that they help you as well.

What is the burndown chart?

The burndown chart falls into a category for me to be viewed as an “information radiator. It provides information in a static way that can allow the scrum master and the team to view the current state of product work within the sprint. It radiates information that can then be consumed and acted upon. It is a great artifact for assessment and course correction as well as allows scrum masters to begin to see items occurring within a team that may not be readily apparent, even to the team itself.

It is a chart that is measured by taking the amount of overall effort to be performed (hours of work) and plotting it across an axis of the total working calendar days of the sprint. Often it is coupled with an “ideal line” that reflects the optimum burn of effort equally distributed among days. As the “task hours” are burnt down, it reflects where the team is in terms of hours remaining to complete within remaining time of the sprint.

A typical burndown might look something like this:

burndown chart

In this scenario, the team has 400 hours of delivery tasks over an iteration of 10 days. This reflects work that may be done by the entire team (coding, testing, design, etc) for the 2 week iteration. So, the ideal line is reflecting to the team that at an average burn rate of 40 combined hours of effort by the team that is projected to complete the committed work within the 10 day sprint period.

Typically  the burndown charts I have used reflect the days of dedicated effort and do not reflect periods of planning, review, etc as these are bookend ceremonies to provide sprint lift-off and sprint landing. The burndown is focused on the time where team effort is directed towards end commitment.

The basic idea behind this chart is that from an agile perspective the highest value is to be aware of the work remaining undone and not to remain focused on the work already completed. So the responsibility of the product team is to reflect the remaining hours daily to represent the actual burn of working on a given story.

This is a very brief and straightforward explanation of what a burndown chart is so let’s delve into the next level of how it is helpful, how we might utilize the information and look at some ways to interpret patterns we may see inside a burndown to better frame questions or make inquiries to the team to help them.

What does a burndown chart do for a team?

As I mentioned before, it is an information radiator to a team. It gives them a snapshot of the past brief period of work and tasks completed and a reflection point for the work remaining to be done within the sprint. This information allows them to reflect a current team state both internally and externally to convey where they are without a “direct status report” to others outside the team as well. Anyone looking at the chart can get a general idea of where the team might be even if they do not fully understand the chart itself. This, however, can also lead to bad perceptions as opposed to informational learning as we will discuss later.

It is incumbent that a scrum master fully understand the purpose of this artifact, the reasons behind how it actually works and to begin to see patterns of work or potential team dysfunction within a burndown chart.

This allows them to not only accurately convey how to use this information and its purpose but frame questions aimed at potentially keeping the team productive or assist the team to be actively  aware of the “first responsible moment” of when a product commitment might become in jeopardy.

Patterns of burndown charts

Visual representation of work often allows an excellent opportunity to the scrum master and the team to reflect on familiar patterns that can be a visual queue to certain information or team dysfunction.

The Ideal Line is merely a Projection

As a scrum master, if you have the belief that below the ideal represents the idea of “being on track” and above the ideal is “being off track” you are taking a far too simple view of the  information that the team provides.

The burndown should be seen as a reflection for consideration of current state of a product development print to make inquiry, not predictive like a project schedule. The ideal is merely a projection of all things working with no issues impacting the team. It is a projection used for comparison. Establishing the thought as a scrum master of anything other than this or reinforcing to the team that it means ahead or behind the curve is a bad precedence to set and can lead to future problems.

Effort Swelling

For instance, in the image above, the team starts on day one burning down tasks and within the next 24 hours begins drifting above the ideal. A simple view might create panic and say “HEY EVERYONE! WE’RE BEHIND ON DAY TWO. WE GOTTA DO SOMETHING!!!!” when the circumstances that cause this picture could result from many potential reasons and should be information we can use as a scrum master to reflect on and potentially frame questions such as:

  • Did the committed work had greater unknowns than the team imagined and tasks are emerging? Normal and very possible. Probably just something to be aware of and see how the trend moves within 24 hours or so. But a basis to have the team reflect on this data maybe as a visual cue to them in your next stand-up.
  • Is the team struggling? Is there a causation? Has the team experienced a drop in overall capacity from the commitment due to sickness, not accounting for a team member vacation, etc? Many modern electronic tools, such as Microsoft Team Foundation Services,  will allow you to adjust the loss of capacity by each team member and the chart will update to reflect this effort recalculated across the iteration.
  • Are they just stuck? Are they mentioning impediments in their daily stand-up? Is there something you can do to assist or coach them to self-organize around solving the problem through inquiry?
  • A common symptom of a potential team dysfunction is that the members are not actually “burning down” their hours. They are pulling a task into a working state and working on it until done, therefore reflecting the total hours when there is actually less to be completed and then moving it to done all at once. This can show work not moving and so the work remaining can begin to begin a swelling pattern. One way of getting some insight into the pattern is if you see large drops of work following a swell.

Effort Drops (“work falling off the cliff”)

This pattern may look something like this:

Burndown Chart 2

Some questions that might happen when seeing such a drastic drop quickly:

  • Was the work committed less complex than the team thought initially and they just hit a “rapid burn” (Go Team!)
  • If following a swell, is the team actually burning down the hours regularly?  Are they perhaps holding on to tasks and not updating remaining hours but just pushing it to done when completed? This might prompt a scrum master to look into this information that the burndown provides in combination with the sprint task board and use it during a retrospective for exploration of “what does this mean to the team”?

Again, the key takeaway here is that these types of patterns provide an opportunity to learn, observe and inquire to assist you as the scrum master to help the team remain productive towards meeting their commitment. This information can help you teach the team to use this information to get some insight as to what is going on either during the sprint or used for exploration with the team within the retrospective.

These are merely some simple examples of how this artifact of the scrum framework can be used. It is best to keep in mind the concept of how it reflects back information to the team. Many scrum pioneers have discussed “BVC’s” (big visible charts) of which this can be one to help teams reflect on their current state of work and make adaptations based on insight. I hope this blog post allows new scrum masters a new way to use this artifact and can help them assist their teams with better insight …

I often consider this quote when thinking of a burndown chart in relation to teams …

“Information is only useful when it can be understood” – Muriel Cooper

 

 

 

Let me tell you a story …

“It’s like everyone tells a story about themselves inside their own head. Always. All the time. That story makes you what you are. We build ourselves out of that story.” – Patrick Rothfuss, Author

 

How did it all start?

My journey started with a personal quest to transform the way I work and delivered value. I was deeply embedded inside a V-model culture in which the end result not meeting customer expectations was typically blamed on the customer.

I started my journey by annoying my manager to allow me to create a pilot project (of little significance to appease me) for my organization after reading about the scrum framework. I knew that this was going to be the wave of how organizations began to work and saw a clear path as to how it could benefit the government sector. So I prepared, I studied, I learned, I asked questions and became immersed in how this worked.

I was given a small team of what I will call “the usual suspects” which were made up of long term employees who were pretty adverse or afraid of change, an assigned “product owner” (who they decided a project manager fit the bill) and a stakeholder who had no idea what I was trying to do. My goal had been stated to conduct this pilot and deliver my findings on if it could benefit this public government organization and what type of staff would be needed to sustain it. So here I was, new team, no idea what this crazy person indicating he was a scrum master (with no experience) asking them to work in a new way in which they would drive their own work, a product owner who needed to understand the role and learn to “lead a team without authority”. This seemed like a real challenge. So, I was all in.

How I got started with my first team …

I started by gathering this new team together and explaining very simply the framework, the roles and rituals and how sprint cycles worked. I was met by questions such as:

  1. What do you expect us to be able to deliver in 2-4 weeks?
  2. Where are the requirements?
  3. How will I test an application without requirements?
  4. You want us to sit together and work collaboratively? What about my cubicle?
  5. What do you mean we determine the amount of work we will deliver? Who manages the project?

And many, many more. I addressed each question as best as I could, remained confident and worked to gain their trust. I assured them that I would be right there with them and help them work through any problems as they arose. I assured the product owner that I would work directly with him to become “team ready” so that he could build his product.

Everyone left the meeting unsure of what lie in front of them.

The initial process …

Needless to say, it was tough the first few sprints. I had to guide the team to understand what “potentially releasable” meant. I had to teach a project manager an entirely new set of skills and way of working and how to establish trust in his team to turn his needs into product without use of command and control. I had to reassure stakeholders as they saw partial software being built out along the way. I had to teach a team, how to conduct a daily stand-up, use a task board and burndown hours. I spent countless hours coaching nervous team members who were so far from the way they worked that they were doing this amazing thing that had never been done before.

Although there was a lot of fear over how they were working, through coaching and support they began to move as a team.

The end result and learning

In the end, the product delivered was a success. It was not that it was a highly prized award winning software package that carried the value that we would have liked but it lit a small spark for some people as to a new way to work.

This team had learned to work together, enjoyed the work they were doing and felt in control of delivery once they found their rhythm as a team. The newly anointed product owner saw benefit in the way he worked in this situation and began asking me how he could “be more agile” in what he did. The stakeholders were happy with the end result and the software was delivered in weeks instead of months.

So, I sat down and typed up a summary of the experience, the overall process and how it shifted roles and needs within the organization, an estimation on what type and level of staff would be needed as well as a recommendation to start small and grow over time as opposed to a large scale shift.

The report was presented to the director of the organization who summarily dismissed the approach indicating “we are never going to do this” (firmly believed in the waterfall approach). I think he may have even thrown it in the trash.

Although disheartened, I knew that this was the right thing to do, especially within the government sector to bring more value through focused iterative work. So, I began to plan my exit from the organization in search of somewhere that I could actually make a difference.

The Partnership …

Coming off of this pilot project and more determined than ever to see this way of working take a foothold. Some leadership shifts had begun to occur and I knew of one other individual within my group that seemed to work slightly differently than the standard PMO. His background was in product management and he treated his product in a different manner than the other project managers. So I approached him and told him about the framework and said “I think you should look at this, you are doing about 80% of it now. You just need the discipline of the other 20%”. He read through it and was intrigued but struggled to get through the scrum guide as it felt like it was more engineering focused. I referred him to the agile manifesto upon which it was built and these values had a much more resonating effect. He became curious. He was a marketer and I had a vision for working in a better way. We were the perfect storm brewing.

As we were both ready for the next challenge, we created a skunkworks project with a new assistant director sanction. We created a team room and sat about to deliver the first product of larger business need using scrum. My new product owner new of a 109 page report delivered to the Commissioner that outlined business related projects (both in planning and “in flight”), their timelines, their progress, etc. It was in an effort to support his regular visits with community leaders with a group of organizational leaders so that he could hold conversations about items specific to the area and be aware of current status as he held the conversations. This report, we later found, had never been looked at by him.

My product owner had the idea that we should produce an interactive map application that could be used on a mobile device so that executives could review this status anywhere and use location as a way to get to these items prior to meeting without going through the hoops of asking a cadre of other people to compile and sanitize the data. I believed that domain data should remain where it lives and that this application should be decoupled from these core business systems yet reflect real-time changes to the data. This had been the debate for many years within unsuccessful committee after committee of how you “connect” the information into a  unified view always resulting in “it cannot be done” or using mechanisms to scrape data from one system to make it visible to another. The problems were:

  1. Once scraped, the ownership of the data in question became transferred to the new owner who was unlikely the owner, therefore would not recognize errors within that domain or ensure that it was accurate.
  2. This was something that actually forced a cross organizational work effort within the business and a base level understanding of owners and consumers of data.

Our theory was through the building of this application we could do several things:

  1. Eliminate a 109 page report that people rarely looked at.
  2. Create a locational context to the data making it more meaningful
  3. Solve a long standing business issue into connecting multiple domain sets of data and giving them visibility.
  4. Create a lightweight tool that since it did not create data but use the data at rest, would allow for quality control in terms of how the data was actually reflected.

So my experience of all of a few months and my colleague of zero months sat about to do the impossible at the time. Create a product (which was not the term used, it was always project in our world coupled with plans, committees, governance, etc) built using the agile framework of scrum with a small but motivated rag tag bunch of team members wanting to do something different and believing they could bring value to the organization. Sounds like a tall order. It probably was. But why was it a good choice?

  1. The product we chose had immediate business value and visibility to the highest level of leadership. It could be a product they would actually use.
  2. It solved organizational problems by connecting disparate data sets and visualizing them in a geospatial context.
  3. It rallied a team. Teams were being demoralized each and every time they worked so hard on a product for many many months just to be told “this is not what we wanted”.
  4. It was focused on value, transparency and visibility. We welcomes anyone to observe how we worked, what we were doing and communicated openly and often. We littered our area with BVCs (big visible charts) indicating who we were building the product for, what the features were and the current progress.

So after putting some solid time into product planning (understanding the need, identifying personas, creating a vision and decomposing high level needs into features) we started with a cross functional team of developers and I played a dual role of scrum master and tester (which I do not recommend of possible). Being cautious, we selected a horizon of 30 days for our first sprint (which probably ran slightly longer as we were learning).

At the end of this cycle, we had a releasable product. Did it do everything wanted? No. Was that the point? Yes.

We demoed the product for the director (who as you recall said we would never do this) who was looking for a win with management. As my PO reviewed the features, the director asked several times “and you built this in a month”? He had no idea that this level of work could be accomplished like this, without the tomes of documentation, the endless committees and death-march approach of a 9 month waterfall effort.

Excited by what he saw and eager to show his leadership value to the executives, he arranged a demo with us and the COO and CFO (even though I am unsure of he understood what had been done or why). Although the first iteration was primitive, they saw the value of this product and method of solution delivery. A rapid innovative solution meeting a business need by people who wanted to respond to change. They immediately scheduled a meeting for us to demo to our commissioner.

Demo day with the Leadership Team

We arrived and setup our demo for the room. We had gone through how we would demo the features and planned to show how it worked across multiple devices so that it could be accessed anywhere. We, perhaps naively, assumed this would be IT, the COO and CFO and Commissioner. The room filled to the seams. Apparently we had stepped on a lot of toes of people who had been promising a solution to this issue for years. They all stopped in to see and, in my opinion, find that one gaping flaw that proved they were right in the impossibility to solve this. Our top leader entered with his staff and off we went.

I produced the 109 page report that this replaced and was immediately struck by the confusion on the commissioner’s face. He had never seen it or if he received it, never read it as it was like a car manual that was designed for the people doing the work, not to help people understand. We continued our demo and I handed him an iPad with the application displayed so he could play with the application and replicate what we were doing on screen. He became more engaged. We were excited and wrapped up the demo for the room.

With a brief pause the commissioner asked “who told you to build this”? We replied “no one, we knew it was an open question that the business had and we wanted to provide value”.

He then proceeded to do what I would call “beat the application with a proverbial baseball bat” telling us all the things it did not do or he wanted it to do. The PO and myself hung on his critique and I scribbled notes so we could process them later. The director looked like we had just shot him in the middle of the room. His perceived “win” seemed to be going south and here were the two guys to blame.

Once the review finished, the commissioner rose and said “I’ve got another meeting but you guys are 100% on track” and left and all of the spectators (many of whom probably felt we got what we deserved) filed out leaving the COO, CFO and IT staff behind. The C level executives apologized for the reaction and the IT director seemed to be disappointed we showed “incomplete software”. But we responded in a way that shocked the room …  “This was great! We now know what he did not like and we can pivot and begin adjusting those features”. We explained that this how this worked. We review regularly with stakeholders, receive their feedback and adjust course as needed. They may have though we were a little nuts. I know a lot of the IT leadership did but with the excitement of the executives, we were given a reprieve to continue.

Within one more 30 day sprint, we had a version that met the needs and it was being used in the field. It was the fastest delivery ever done from a team of 3-4 as opposed to 5-12 over a 9 month period after 9 months of requirements gathering beforehand. We held conversations surrounding value and need, not features.

My PO was made CIO following the success of the product and asked me to stay on and transform the organization to work like this on every product. 4 years later and we have 4 scrum teams, 5 product owners and other pockets of agility. Even our own HR for the organization has become trained in kanban and uses it for their HR projects. The business extrapolated the idea of the scrum team to create “business studios” made up of all of the team members needed to complete a business function for a core business line.

How I planned to Build Something New Here …

When the PO moved into the CIO role he asked me to stay and help him build something new. I agreed under 2 conditions:

  1. I needed to be able to always call BS when I sensed it.
  2. I needed to be trusted and left to build it right.

He agreed (although he may have thought I was a bit nuts, and still may).

First, I knew I could not do this alone. Although I had a significant technical background in all aspects of software delivery, I had to follow the advice of “getting the right people on the bus”. So the initial team for this organization was hand picked and recruited. They were either excited to do something new or brought in superior technical skills and strategy to build out a solid technical architecture. I remained personally involved as a scrum master and tester (as we did not have much depth) and we stayed strictly adherent to the framework (look at the Shu-Ha-Ri principle).

Once I was able to move into more of a leadership role, I set about doing a few things that I think, although small, made a big difference.

  1. This new organization would be align as flat as possible to encourage self-management and self-organization. Everyone reported directly to me to support the people doing the work determining how the work would be done. This did not change until the group had significantly grown and it became necessary to add a layer.
  2. Continuous learning for the group would be core to the values of the new culture. We identified a great online technical education resource which we procured for every staff member and the idea of a “lab day” in which they built upon their own skills following each sprint became standard practice.
  3. The idea of team protection and focus from distraction was also a core principle. We minimized disruptive impact to the focus the teams and encouraged, coached and empowered them to take commitments seriously by ensuring that the people doing the work indicated the commitment of work that could be done.
  4. I hired a couple of eager team oriented scrum masters to be servant leaders to the teams and help them mature.
  5. Ensuring space was available for the team members to innovate and exercise personal creativity. Outside of the standard lab day within the cycle, I self-funded and piloted a hackathon which is growing into a larger and wider event for the broader organization.
  6. Hiring became focused and central to our growth. We broke out of the typical mold of the state process in which an applicant performed a 1 hour interview in which they regurgitated their resume and convinced you to hire them. We implemented 3 hours interviews that combined not only behavioral based questions to gauge how they had responded in the past to situation or might do so as well as a 2 hour technical interview in which the expectation was that they demonstrate the skills needed to do the role for which we were hiring. This has been something we have maintained focus on changed over time as opposed to making it a standard approach. I strictly adhered to the rule of “hiring the right person” and if they did not show up, I hired no one (much to the dismay of my leadership as the public sector hiring process can be cumbersome). I truly believe that this helped us create sustainability by making good hiring decisions.
  7. I placed equal focus and attention to the cultural and technical growth aspects of the group. I hired people that were “culturally additive” in terms of value and with the help of strong technical leaders we defined and adhered to an architecture complete with design patterns, branching and merging strategies and promotional process. Defining this initially but leaving it to the technical people to grow has done well. I tried to be very intentional to create some growth paths by not hiring for every position so that people felt they had to leave to get ahead.
  8. Instead of overloading a lot of processes (outside of the rules that were outside my control in the public sector) I imposed a litmus test for decision making composed of (2) key elements of consideration. Is what we are seeking to do “reasonable and responsible” to ourselves, our team, the citizens, our organization? If it met this litmus test and we understood and accepted the personal responsibility of the risk, remained transparent to those involved or impacted, the people doing the work had the complete freedom and support to make good choices without committees, work groups, management hierarchical approval, etc.
  9. I established the idea of creating tribes within the organization composed of people with a passion to solve a problem that they created themselves and managed. This applied to everything from how we celebrated birthdays to our recurrent staff meeting to process improvements.
  10. Everyone had a voice. Starting with everyone reporting to a single point it was easy to establish that anyone had the right to speak out. I reinforced this to staff by being an advocate for meritocracy, not democracy. “Good ideas come from where they come from” was the guiding idea.

In doing all of these things, I learned a lot. I challenged a lot of preconceived ideas of how people operations worked and how work got done. I have to say, although there is always room to improve and grow, I am very proud of the teams that are here today. I have had a few people move to new opportunities (always in a positive way) and seed groups of their own or seek to take aspects of the culture and apply it to new organizations.

While I have always hated to see people leave, I treated this as a good thing that they were growing and not dwelled on any gaps it left behind, which I think has been encouraging to them and not created undue organizational stress. So many public sectors operate in fear of “that one guy” leaving as they carry so much legacy knowledge. They do not stop to realize the problems is in the silo of knowledge as allowed by the organization, not the person themselves.

So why did I share this journey?

Some might think it is for the purpose of braggadocio. Nope. While I am proud of where I am and where this organization has grown, I see miles of potential unrealized before us. I think we are where we need to be today and hope we continuously inspect and adapt to get us where we need to go to become truly high performing.

I have heard many stories that amaze me on how people shaped their work world and I take personal pride in what I do and am impressed by the strides of many others. I have tried experiments that have succeeded and some that have failed miserably. I am very fortunate to be in an environment that has allowed me to do this as they know that I am aware of risk without sacrificing the need to experimentation. I truly am grateful for this opportunity.

Personally, I am grateful for everyone I work with from the most agile person within the organization to the person that is struggling just to figure out how they fit in the agile space. The former because they focus on value as a driver in the way they work and the latter because they want to learn, adapt and grow most likely or find the way they can connect with something different.

I take pride each and every day knowing my teams are in control of the work they do, take their commitments seriously and work to deliver quality products to the best of their ability. I take pride in seeing the depth of people we have and how those differences make them a more solid team as a whole. I am humbled by the fact that a great deal of people took a chance to try something different and trusted that we were building something great. I take pride in building an organization in which and every person has a voice in their work no matter their role and that teams are protected when they fail from being vilified and  are asked to use these as learning opportunities. I am proud that my teams know the value of the “first responsible moment” when encountering problems and raise the flag to draw the attention when it happens so that risk is managed in real-time as opposed to being based on a risk register outlining risks that may or may not ever occur.

I spoke at an agile leadership summit about 6 months ago and one of the other speakers said “you should tell stories more, you have a knack for it” (unsure I agreed but appreciated the compliment). I actually did tell the organizer that if they had a rocking chair available, that is was best not to place it where I could sit when giving my talk or I might keep folks for a while. Yes, I love to share things with others. Perhaps it is in my nature and wired within my regional DNA in general.

The reason I share  and this story is that I want people who may be struggling with a transformation or even just getting started to have hope.

Hope that you personally can do something different and affect change. I helped drive the implementation of agility in the most unlikely of places at a time when “death marches” of project failure were accepted in the culture as the standard practice of work and the value add by IT in general was viewed as very low by the business. From this small product, we transformed an organization and a culture and started a broader conversation that continues today. I often tell people when I started this conversation, I was the only person in the room (which meant a lot of talking to myself). I recently attended a meeting where 10 people engaged in a conversation of how to apply agile conversations more broadly and have coached, mentored and shared this story with a lot of folks over the years.

I alway recall a quote that inspired me early on from Mike Cohn.

“Agility is not something you become. It is something you become more of …”

If you’re stuck now or things are less than optimal. Stop. Take a breath. Figure out where you can pivot and where you can persevere. If you are unsure where to start, find that thing that you can make valuable and start “starting”. Be as agile as you are able to be given constraints and then push to become more agile. Learn from failure, embrace feedback, push yourself and do not compromise or collapse in the face of adversity. Show people a new way to work and build a culture that drives to empower and trust those doing the work, not operating under command and control.

I am going to end this quote with a passage from Apple’s “crazy ones” ad campaign created by Rob Siltanen and hope you all stay agile!

“Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently.

They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things.

They push the human race forward. And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.”

 

Capacity and Performance

“Your capacity to say no determines your capacity to say yes to greater things”        – E. Stanley Jones

This is something in business we all struggle with in my assessment. How to sequence “just the right amount of work” to deliver value and still all the desired ability of an organization to remain responsive to shifting value needs. My organization has struggled with it as I feel confident many of you have as well.

There are a lot of techniques, both agile and not, to determine capacity and we’ll look at a few and I will express my own opinions here and what effects poor capacity planning can have on teams and organizations.

Somebody call 911!

A lot of us live in a world of “firefighting” as an organization. Not literally, but what I mean is that we become reactionary as an organization as opposed to responsive.  Organizations often confuse responsiveness as the ability to handle each fire as it occurs when it reality this is chaos at its core. Often, these organizations are so busy fighting the blaze that they never take the time once the situation has passed to ask why the fire actually started in the first place or they confuse every flare up on the same level as the entire city in flames. This is not responsive, it’s reactionary and although you may be defined as the “hero of the day” in the moment, it eventually raises much deeper problems that can become exposed and have to be addressed.

Being a reactionary environment is inefficient. It means that there is a significant amount of waste happening waiting for the disastrous event or worse yet it is a sign that work is improperly sequenced to allow a balance of responsiveness and performance. Signs of this are often team member turnover, sick time increases, increased deep policy to attempt to be preventive (the “ban all matches” approach) or just a general negative outlook to solving a problem. Be vigilant in observation for these types of issues as one you define yourself as this type of an organization, it is often very painful to change.

Capacity, Performance and the myth of being busy

One of the things that I have always believed is “do less better”. Ensure that you are meeting the highest value items for an organization but in the face of emergent needs you have to deliberately create slack within your work capacity for numerous reasons. Things like actually being responsive to the emergent pet project that comes up, capacity to nurture your teams and team members to allow them to grow and give back to the organization in doing so and generally to improve performance throughput

Basically capacity boils down to “how much something will hold” from a true math reference bt in our terms it means how much time and work can we consider and remain effective in our performance. Finding area and volume of a given shape to determine capacity is a relatively simple formula but when it comes to people and time, it often gets tougher (although I know many PMP folks who would explain to me formulas of resource management, resource being a word I strongly detest when referring to “people”).

A general rule of thumb is that you will never receive the maximum capacity of a given person or team. Accept this. If a person works an 10 hour day, the best you can hope for us 70%-80% which is roughly 7-8 hours at the high ends. The reason for this is that people are social creatures and have needs like going to the restroom, checking emails, diverting their attention after prolonged focus, casual conversation, meetings, etc.

If there are CIOs/CFOs/COOs/CEOs reading this in awe and shock, welcome to the reality of people. And it is even possible that 10% of your overall workforce is performing suboptimal based on lack of skills, poor work ethic, sickness, burnout or whatever reason. So how do you handle this and still maintain a level of performance without remaining in a constant hiring frenzy of cycling burnout workers?

First, accept your reasonable capacity levels and plan strategically. If you do, you will find that you optimize the flow of delivery within that capacity and you often see higher percentages executed (which can be a different topic to watch for … “dark work” that has no visibility and creates strain but as things are delivered on time no one questions).

If you think more bodies are the answer. You’re wrong. Read the Mythical Man Month. As you increase complexity to any systems you fragment pathways making performance degrade. Think of a small intimate dinner gathering and how conversation can flow well between 2 couples (as they can keep up with topics or break into smaller sub groups and still reflect to the group). Now introduce 2 more, and 2 more, and 2 more. Make it a large dinner party and afterward come home to discuss the topics of conversation. The pathways are too complex. You cannot keep everyone in the loop on all of the conversation occurring.

The same thing occurs with software development. As you introduce more and more staff you increase the complexity in the forms or handoffs, communication pipelines, individual or small group decisions that get made, etc which make it slower as rediscussion, rework and deeper changes are often a result. This is often why I prefer product feature teams as opposed to component teams whenever possible.

Secondly, if you want to be responsive; be deliberate in building in slack to your approach. Let’s take 3 examples; road networks, servers and teams.

Road Networks:

You are driving to work. There are 30%-50% of other cars on the road. You make your commute in a reasonable amount of time. But we are not utilizing all of the capacity of the road! So let’s crank it up to 100% and make that same commute. What is the expected result? Traffic jams, delays due to accidents, road rage. We actually decreased our performance by trying to fill all of our capacity.

Servers:

This is a little tougher as in the day of invisible scalability of cloud networks it may seem a poor example, however, if a server capacity is maximized to 100%, performance degrades; it is a given. It results in unneeded swapping just to meet all requests. It may seem negligible but if you have ever been frustrated waiting for a web page to load, you may have been experiencing exceeded capacity.

Teams: 

Filling a team capacity to the brim can result in whiplash when trying to meet those emergent needs With that allowed focus, you have teams that maximum their throughput through selection, self-organization and a regular cadence. If they have other responsibilities (support, meetings, etc) not building in that capacity that is aware of these things will result in feelings of being high performing but in fact often degrade performance and hide a lot of work being done on an employee’s own time (which can result in a whole host of issues).

But we have to keep people busy

Do we? Did we hire the individual with a specialized set of skills to ensure they remained “busy” or did we hire them to ensure that we had the necessary skills to realize the end result of value?

If a manager pops into a team room and a team is relaxed, having a conversation about Dr. Who or some world event is that ok? Sure it is. If they are personally making their commitments and failing to deliver value, then you might sense a problem which could be everything from they are sandbagging to they are being disrupted externally for other work to the guidance they are receiving is creating deep and counter productive conversations at the time of delivery from a lack of understanding. It could be lots of things.

The point is not to keep people busy. In trying to do this based on observations of social interaction as a sign of low productivity, you toss the idea of capacity out the window. For me, I want a highly motivated team that wants to come to work and deliver because they know they have a direct voice in setting and communicating reasonable expectations for feature delivery. Does this not mean that occasionally the team may not be forced to ramp up commitments to meet a deadline? Absolutely not. But if you trust the people doing the work to be reasonable and responsible in communication, transparency and of the delivery of that work; often times I find teams will rally to address the hard need.

Otherwise they are back in firefighting mode.

Seeking to ensure teams and team members are “all busy” is a false goal. It equates people with server throughput. People should be cultivated and grown if you want to create longevity of any sort in your company with employees. They will become your greatest champions and advocates if you embrace this. They will tell others of the great company they work for and they will work hard to deliver of their commitments.

I write this post today not out of any personal or professional frustration but from an observation that many organizations focus on “busy” as opposed to intentionally creating space to be responsive to emergent needs. Just like a home’s unused space get filled, professional people fill the unused space (through skill acquisition, environment improvement, idea sharing, etc). But just like a home; should you inherit your grandmother’s giant steamer trunk if you have filled all of your capacity of space it gets placed in an odd location or you “make room in the attic”.

Be honest and kind to yourself as an organization, your people and reflect a true understanding of capacity by considering more than just “delivering more” or “being busy”. Understand what other impacts that people have that impinge on capacity and to become truly responsive, be intentional in creating slack within your overall capacity.

As I always say and I will say once again … “Do less better”.

 

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

 

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!