Freepik rendering of the prompt 6 cats in a line one whispering to the next playing the telephone game

Realizing Agile’s Efficiency

(Feature image by Freepik)
TL;DR: Fostering a culture of trust that leads to calm collaboration up front will yield the benefits that Agile principles promise.
Preface: While agile is in the title of this post, no claim is made that the post is about how to do agile or how SAFe is or is not agile. It is about how the Manifesto for Agile Software Development is self-clarifying in that it concludes with “while there is value in the items on the right, we value the items on the left more.” (italics mine), and how the value of the items on either side should be measured by their effectiveness in a given organization and the organizations influence on the “self-organizing teams” referenced in the Principles behind the Agile Manifesto. That said…
The value of architecture, documentation, and design reviews in SAFe was illustrated in a scenario that played out over several weeks.
The situation started with the discovery that a particular value coming from SAP had two sources. Well, not a particular value from the perspective of the source. The value had the same name, was constrained to the same list of options, but could and did have different values depending on the source, both of which were related to the same physical asset. For numerous reasons not uncommon to SAP implementations that have evolved for over a decade, it was much more prudent to fetch these values from SAP in batches and store them locally.
The issue of the incorrect source was identified by someone outside the development team when it was found to be commonly missing from the source selected for work prioritization. For various reasons that will be common across a variety of applications that support human workflow, this was considered something that needed to be addressed urgently.
The developer who had implemented the fetch to the correct source was tapped to come up with a solution. Now, one thing about this particular application is that it was a rewrite of a previous version where the value of “Working software over comprehensive documentation” was adhered to without considering the contextual reality that the team developing release one would neither be the team working on the inevitable enhancements nor ever meet that team. The re-write came about when the system was on its third generation of developers and every enhancement was slowed because there was no way to regression test all of the undocumented parts. Unsurprisingly, the organizational context that resulted in the first version missing documentation also resulted in some tables schemas being copied wholesale from the original application and not reviewed because requirements were late, resources were late, and the timeline was unchanged. So, with no understanding of why not to, the developer provided a temporary solution of copying the data from one table to the other because it had only been communicated that the data from one source was the correct data for the prioritization filter. Users were able to get their correctly prioritized assignments and  the long-term fix went to the backlog.
As luck and timing would have it, when the design phase of the long term fix was picked up by the architect, the developer was on vacation. Further, while this particular developer had often made time to document his designs, the particular service the long-term fix depended on was one of the few that were not documented. Still further, it had been re-design as another service had been discovered to obtain the same data more reliably. But all of the data currently loaded was from the previous version, so even the attempt of reverse engineering the service to get sample data for evaluation was not possible. These kinds of issues can lead to frustration, which in turn dampens creative thinking, which is to say that had the architect looked at the data instead of following the assumption from the story that the data wasn’t yet readily available, he would have discovered that it was already present.
Eventually the source of the correct value was identified and a design created that would favor the correct value over the incorrect value but use the incorrect value if the correct one was not available to allow for the assignments to continue because sometimes the two actual values were the same (which is inspiration about a future post discussing the value of MDM). The design also included updating to the correct value if it became available after the initial values were set. The architect, being thorough, noted in the design a concern about what should be done when the correct value came into the system after the record that was prioritized based on that value has been assigned and processed by a user. After much back and forth, it was finally communicated that while the data was retrieved from the same system and labeled with the same name, the two values were not different because one was incorrect but because they were in fact to separate values meant for two different viewpoints. Which means that the design of attempting to choose and store a single correct value in both tables was invalid and that the records altered for the work-around were now (potentially) invalid. This made the correct solution a (relatively) simple change to the sorting query.
With the full 20/20 vision of hindsight, it is now clear that if the team did not feel that ever issue needed to be treated as an emergency and all of the product, design, and development stakeholders had discussed the issue prior to taking action, about 80 hours of work would have been reduced to 4 hours. Yes, there were other factors that impacted the need of 80 hours to deal with what is a fairly minor flaw, but those factors would not have come in to play had the questions been asked up front and clarity reached through collaboration.
Facebooktwitterredditlinkedinmail
© Scott S. Nelson

The Real Problem with Hybrid Agile

Featured image by Gratisography: https://www.pexels.com/photo/man-person-street-shoes-2882/

Before SAFe®, most organizations would do “our brand of agile”. IMO, SAFe® takes the most common elements of a plethora of hybrid agile approaches and codifies them in to a “standard” (imagine air quotes). My comments today are not about SAFe® but hybrid agile in general.

The common denominator I see across hybrid agile approaches is that they include the notion of some specific deliverables by a specific date. For the agile purist this isn’t agile because that notion is very not agile. Hats off to the purists that get to work that way, and they have already stopped reading by now unless they share the same mental state of people that slow down to look at a bad accident on the freeway (which I feel is not agile, but I’m no purist, so I couldn’t say for sure).

So, having target dates for a collection of stories isn’t entirely a bad thing, in that there are many organizations that have a legal obligation to appear as if they can reliably predict the future. These target days are where the problems start. And I will admin here that the title of this post is a lie, it is multiple problems, but I wanted to rope in those who really think that there is one thing wrong because I think they may get the most out of this particular rant.

So, first problem (position being arbitrary, I don’t have any stats about which problem occurs most) is that if the target is missed then there will be some people that point at the agile side of the hybrid approach as the blame. It could be, but it is much more likely that it is the behaviors that result for hybrid approaches, such as skipping documentation entirely, which results in longer ramp up time and lack of the DRY design pattern, because if you don’t know what’s been done how would you know if you were doing it again?

The next problem (purposely avoiding making it the  second problem to avoid people thinking this is a non-arbitrary sequence…beyond a order that helps to communicate the concepts) is that when the targets are missed the people that are supposed to know what the future looks like look bad, so they get mad at the people who are trying to hit the target. Most people feel bad when people are mad at them (except people with either experience in such things, certain psychological disorders, or a hybrid of the two).  No one likes to feel bad (except people with different psychological disorders) so they try to figure out how to prevent that in the future.  And we have tons of action-comedies to suggest a way to do this: Lower your expectations…lower…lower…that’s it. So people stop missing their targets and Wall Street analysts think the bosses of these people are great prognosticators where what they have actually done is taught their teams to be great procrastinators.

And the last problem I will point at before running for my life from hip hybrid folks who will want blood and purists that stuck around and are still looking for blood is that the people who try to make it happen still miss the mark because they focus on the wrong targets. The long-term goals have this nice, big, shiny definition,  where agile aims to complete one small, solid solution. The magic comes from being able to look at the big shiny and build a small solid that is good-enough-for-now, and still in the direction of the big shiny. One definition of magic is “some can and some don’t know how”, and in the case of this balancing different paths to perfection, some will focus everything on the small solid piece and forget to thing about whether it will fit into the big shiny vision. Or, they will be so enamored with the big shiny vision that everything they do in the span of a sprint is inadequate for the pieces that are solid, making the next sprint slower because they are still waiting on that piece that would let them move faster. Of course, magic is hard, and expecting everyone to produce it is destined for disappointment, which is why the teams that just lower their expectations are more “successful” (Dr Evil-level air quotes there).

So, at the end of the day, or at least the end of this post, the perception of success is easiest to meet if you succeed at level far below your potential. You can stress out everyone and sometimes hit the target. Or you can start forgiving your teams for their imperfections, cheer them for their successes, and teach them to learn from each other to be more successful every quarter. The problem with that last is that I will have to write another post to find more problems with hybrid until they are all resolved.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson
Path with cloudy destination

You can always get there from here

There are many quotes to the effect that perfection is a path and not a location (my wording in this case).  To me, this is the essence of agile vs waterfall (and, to a degree, SAFe).
Agile trusts that high performing teams, following processes that support continual re-evaluation, will produce higher quality deployable results with the same amount of resources.
All methodologies have processes (or ceremonies). Properly followed, they can all produce good results. Whether one methodology will produce better results than another is fairly moot, because it isn’t the methodology alone that influences the results. It is where the focus of the team is while following the methodology that makes the difference.
A team that is focusing on a date will almost always have to skip some steps to make that date.
A team this focused on the completed product is almost always  going to miss an import use case (very simple products excepted).
A team that is focused on absolute perfection of every task is going to miss business expectations.
A team that is focused on sticking to an iterative process and willing to course-correct their approach to improve the next iteration will always produce better deliverables.
Leadership is less about providing direction and more about communicating where the team should focus to be successful. The goal is to have a shared vision and foster the flow state that will support realizing some version of that vision at regular intervals.
Or, to use another similar quote, “This is the way”.
Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Too big to survive: There is no bailout for technical debt

The only difference between technical debt and financial debt is that costs are more often known in advance when taking on financial debt. Both types of debt are a tool when used intelligently with purpose and a plan to manage it and can take a devastating toll when used recklessly or imposed through misdirection or miscommunication.

Acceptable vs unnecessary debt

The original heading here was “Necessary vs unnecessary debt”. On further reflection, though, I realized that the only good reasons for incurring debt are time drive. If time is removed as a factor there is no reasonable need for debt. So then it becomes a question of when time is important enough of a factor to make debt acceptable.  The only context I can think of where time is universally an acceptable driver for debt is in an emergency situation.

Beyond an emergency, the evaluation for whether debt is acceptable because of time becomes a value proposition. In our personal lives, the first car and house is generally considered to be a good reason to accept debt because both have a large enough cost where they are likely to become more expensive over time, making it harder and harder to save for them in a reasonable period of time.

Similarly, building in-house custom applications rather than waiting for a Common Off The Shelf (COTS) solution that will incur technical debt in minimally reviewed code and the inevitable maintenance costs is worth it for functionality that is key to business value. Having worked for software vendors, I can honestly say that it if it isn’t already Generally Available (GA) as at least a patch one then it should still be considered unavailable as a COTS solution.

The other common time driver that should generally not be an acceptable reason to take on debt is impatience. Using a home equity loan to buy the latest television is a poor financial decision and implementing a new solution without a thorough evaluation and proper training is a gamble that will usually result in higher maintenance cost or a potential system failure.

The old adage “patience is a virtue” is not only true, it is a vast understatement of the value of patience.

Stop debt before it happens

The reason technical debt is becoming an increasing concern at many companies is because it tends to grow exponentially, just like financial debt. And for the same reasons. Of the three drivers for debt mentioned previously (emergency, long-term value, short-viewed impatience), the most frequent cause is the least necessary. Impatience. Problems arising from bad habits will grow until the habit has been replaced by actions that have a more positive effect.

Without getting too psychological here, impatience is a result of either wanting very much to move towards a reward or away from loss. For some odd reason, the drive forward doesn’t seem to repeat in the same context nearly as much as the drive to move away from. In technology, the drive to move away from is so common that the three key emotions related with impatience driven by escape have an acronym: FUD (fear, uncertainty, doubt).  In the case of IT decisions all three are essentially redundant, or at least a sequence. Fear driven by uncertainty and/or doubt. When the decision is around taking on technical debt, the fear is that business owners or customers will be upset if the feature is delayed or reduced and the uncertainty and doubt are the result of either not asking these stakeholders or asking only half the question.

Asking a stakeholder “Is it a problem if feature X is not in the release?” will frequently have a different answer than “Would you prefer we include feature X in a later release or risk certain delays to all future feature releases by pushing it before we have time to include it in a maintainable manner”? My experience is that most of the time neither question is asked and it is just assumed the world will end if users don’t have access right now to a new option that only 3% will ever use. It is also my experience that when the tradeoff of reliability and stability versus immediacy is explained to stakeholders they usually opt for the delay. I know many people believe that businesses have lost sight of long term implications and I believe that in many cases it not because they are deliberately ignoring them but because the people that should tell them when and why to be cautious are afraid of saying anything that will be considered “negative”.

To summarize, the best way to reduce the accumulation of technical debt is to have open, honest communication with stake holders about when decisions involve technical debt, the consequences of that debt, and the options for avoiding taking on the debt. Then, if the decision is to still choose the right now over the right way, immediately request buy-in for a plan, timeline and budget to reduce the technical debt. Again, my experience is that when the business is presented with a request to ensure functional reliability they frequently say yes.

Getting out of unavoidable or accepted debt

Taking on some technical debt is inevitable. This is why the modifiers usually, most often, and frequently were used in the previous section rather than more-comforting-yet-inaccurate always, definitely, and every time. Even in a theoretically perfect process where business always opts for debt-free choices and emergencies never happen, there are still going to be debt-inducing choices made either from lack of information or usage of imperfect vendor releases.

In the case where the debt is incurred unknowingly, once it is discovered be sure to document it, communicate and plan for its correction. The difference with cases where the debt is taken on knowingly because it is unavoidable without a much larger cost in vendor change, monitor the item with every project and when there is a reasonable option to correct it, do it. I once had to build something that was a bit kludgey because the vendor application clearly missed an implication of how a particular feature was implemented. We created a defect in the defect tracker which was reviewed in every release. 18 months later, the vendor found the error, corrected it and we replaced the work-around with the better approach in the next release. For major enterprises it is a good idea to raise a support case with the vendor when such things are identified, which I did not do at the time because the company I was managing this application for was too small to get vendor attention and the feature was not in broad use.

Originally published at InfoWorld.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

How Salesforce Supports Citizen Development

Citizen development is really a responsible response to the dilemmas created by Shadow IT. Now that technology is available to those with minimal technical knowledge business users will implement solutions without the help of the IT department. The best thing IT can do about this is mentor the business users in ways that will support what business is going to do anyway in a way that will not lead to enterprise-level headaches. Salesforce is at the forefront in helping business and IT with this new paradigm.

The number of times I revised the title of this post is a sign of the times in technology. Those not steeped in the gray arts of technology may think that since computers process 1’s and 0’s that going from thought waves to software is a linear and clearly defined path. The more the technology evolves the less true that is. I started with the title of “How Salesforce Enables Citizen Development”, but a key premise of this post is that it is not a check box in the system administrator’s console, which the term “enables” insinuates. “Citizen Development with Salesforce” was considered and rejected because it has a tone that suggests that there is no longer a need for highly trained Salesforce administrators, architects and developers. Not only do I disagree with that premise, I more emphatically caution against the invalid assumption that such a void would result in cost savings. These nuances of title may seem like a lot of over-thinking except that as both a writer and reader I am all-too-aware of the tendency to base a fully formed opinion on the title alone.

I was recently asked to sum up the benefits of citizen development and came up with the following:

  • User-owned Solutions
  • Reduced IT Bottlenecks
  • Streamlined Process
  • Lower Costs to Deliver

Salesforce supports citizen development by providing a platform with capabilities that can be accessed and utilized with a minimum of training and experience. The unbridled optimist will look at the preceding sentence and imagine a world where every business user can build applications that are easy to use and will contribute to productivity at a lower cost.

Citizen Development Bumper Sticker Policies
Citizen Development Bumper Sticker Policies

The realist would (and should) take umbrage with the word “every”. Putting aside the variance in individual capabilities, there are other key factors that make “every business user” a dangerous assumption. Two key factors are time and inclination. It takes both to perform any one of the following critical tasks for a successful application:  Determine the full range of business requirements an application should address; analyze the variety of technical solutions and appropriately select the best fit for the requirements;  review the existing functionality within the organization for potential reuse and impact; train and support other users in the resulting application; and maintain proper data governance to ensure both adequate security and cost controls.

So, perhaps a better statement of how Salesforce supports citizen development would be “Salesforce provides the tools for an enterprise to enable business users to build applications with little or no IT support when proper governance processes are established and followed”. This phrase doesn’t fit on a bumper sticker as easily as “Clicks not code”. Perhaps “IT doesn’t go away. IT gets out of the way” almost fits, though.

The “lower cost to deliver” benefit is based on the streamlined process of citizen development, i.e., no need for business to create a full specification to hand off to IT for implementation since business will own the development. In an enterprise where the IT team is continuously backed up, this will lead to faster time to delivery as well. In cases where the scenario is simple or common enough to be configured in a generic manner, a great deal of time can be saved. However, this should not be confused with the false assumption that configuration over coding is inherently faster. Sometimes it is and sometimes it is not. Declarative programming must be provided in a way that is maintainable by the vendor and generic for the customer. For a skilled developer, custom development can be completed in far less time than it takes to configure a collection of generic options to something as simple as loop through a specific set of data looking for a specific output.

If it sounds like citizen development is a bad idea that is neither the case nor the intention. Application development is like raising a child… it takes a village with each member contributing their specialty at the best time and in the appropriate context. A governance group to provide guidelines, consider exceptions and enforce adherence; Architecture and security specialists to determine the best way to ensure compliance; Developers to provide reusable components when they are not readily available from the App Exchange; Trained Salesforce system administrators to enable appropriate permissions, configure necessary integrations, and manage production deployments.

In short, all of the roles that an organization following best practices for platform use will have in place anyway. On the one hand, supporting citizen development adds some additional tasks to those who support the platform. On the other hand, properly supported citizen development frees up platform support personnel to better focus on the tasks that most need their skills while improving relations between business and IT by enabling business to more self-supporting.

Originally published at InfoWorld

Facebooktwitterredditlinkedinmail
© Scott S. Nelson