Are you developing too much code? The rationale for low code alternatives in digital transformation programs

Too much code
I am concerned that some organizations are developing too much custom code as part of their digital transformation programs. The code may be tied to delivering new mobile experiences to customers, integrating new data sources into a data lake, generating dashboards, or providing collaborative tools for a departmental workflow. Writing too much code can be a mistake for organizations when supporting and enhancing the code becomes more difficult than anticipated.

It’s easier to write and deploy code today than ever before. Set up a cloud, select a development language and platform, download an editor, setup one of dozens of data storage services, decide on a basic testing process, commit code to git, develop a rudimentary CI/CD pipeline … There's plenty of "how to" videos and tools to get developers started with the basics, or, organizations can hire a freelancer or service provide to do all the heavy lifting. Two weeks you have an app and in two months you are at MVP.

Developing custom code is NOT that easy!

Sound easy? I promise you that it’s not. I just rattled off a half dozen technologies not including all the open source or third party libraries that are leveraged in the code base.

Watch a developer debug a difficult performance issue, solve a complex user data issue, or resolve a conflict in how a browser version interprets a CSS.

I have deep respect for developers working through these issues. Even with the best code standards, debugging tools, and runtime performance monitoring, it can be difficult and time consuming to research and resolve application defects especially if they only impact a subset of users.

And business leaders need to learn and relearn the patience it takes to build and support a custom application. Something what looks like an easy implementation or a quick fix often takes a lot longer than anticipated. One of the most common questions I get from business managers is, "Why does [fixing it | developing it | resolving it] take so long?"

And therein lies my concern. Most business leaders don’t have this patience. Many businesses don’t allocate the budget to support upgrades and enhancements to applications. Only the best of developers write code that is easily maintainable by other, often more junior developers. Few organizations invest enough in developing automated tests and documenting their code. 

And with many platforms and open source libraries being released more frequently, businesses face a lot more risk if they don’t actively upgrade applications.

Why are you developing so much custom code?

It’s good that organizations are looking to develop more applications. It's GREAT actually. Some of these applications are products that drive revenue or customer facing applications that improve end user experiences. Some are workflow applications that make employees more efficient or enable them to better collaborate on business needs. Other applications may be tied to data integrations or analytics programs. Again, all good stuff!!

But not necessarily good for organizations that elect to develop custom code for all these business needs!

I believe there are four reasons organizations are developing more custom code -

  • Business and technology leaders do not invest sufficient time to research platforms, implement proof of concepts, and promote platform-backed solutions to stakeholders. When investments for new applications are justified, the organization doesn't have the time to research and falls back to developing proprietary applications.  

  • Product owners drive requirements toward solutions that can only be implemented with custom code and they are reluctant to compromise when alternatives are presented.

  • Some CIOs are reluctant to bring in third party platforms, sometimes because they fear experimenting before their is organizational support for platform driven development and sometimes because they are concerned on being locked in to a vendor’s proprietary tools.

  • Many developers prefer writing proprietary code over using technologies like data integration, low code, BPM, and other platforms that require less and sometime no custom coding. 

Identifying low code and no code alternatives

So what should organizations do differently? What enables them to seek out platforms and tools that can enable delivering more capability with less code?

The simple answer is to do more research, review, and POCs of the alternatives. In almost every major category of application development need, you can likely find platforms or tools that enable development with less or no coding required.

Need a content management system? I can list at least four. Need to integrate data from disparate sources then I know of six that can get you started. Need to develop mobile first applications for the enterprise then there is at least another half dozen. BI - yes. Even AI and blockchain has emerging platforms that will enable experimentation with less coding. Contact me if you want to discuss!

It's a cultural issue, not a technology issue. Organizations that have a DIY (do it yourself) or a NIH (not invented here) culture have to tackle these beliefs.

Don't leave a legacy of too much code behind.

Further reading on low code 

continue reading "Are you developing too much code? The rationale for low code alternatives in digital transformation programs"

My Driving Digital Advice for Chief Information Officers on CXO Talk

If you missed my appearance on CXO Talk on Friday, here is your chance to catch up! Thanks to Michael Kringsman for having me on the show!

We covered a lot of ground in forty five minutes on how the role of the CIO and technology organizations has changed over the last few years and why it will continue to change.

Watch the video here and learn answers to several questions on leading digital transformation.

How should CIO partner with their business colleagues in defining a digital strategy? How to speak the language of the business? How can lowcode and citizen development platforms drive innovation? How should CIO discuss, market, and sell investments in security and governance? How should CIO partner with Chief Digital Officers? How do you find business sponsors that will be early adopters of  digital transformation programs and how do you manage detractors to the agenda? Why should CIO invest in their marketing and communication skills? Why do CIOs have to move smarter and faster?

Special thanks to Michael and CXO Talk. Final bit of advice is to subscribe to the CXO Talk YouTube channel.

continue reading "My Driving Digital Advice for Chief Information Officers on CXO Talk"

Benchmarks for Healthy Agile Planning that gets User Stories Written and Estimated

Agile practices, and scrum in particular are really strong at prescribing steps to go from sprint start to end. Teams practicing scrum will usually have a commitment meeting at the start of the sprint to decide the scope of work they aim to complete and daily standups during the sprint to discuss status and blocks. At the end of the sprint there should be a demo for product owners and stakeholders. Most teams also do  a team retrospective to discuss what worked during the sprint and to identify process improvements.

Teams adopt different release management practices to go from sprints to releases. Organizations that have implemented continuous integration and continuous delivery pipelines and other devops practices often look to release frequently, while others that require more end user communication or training look to normalize a release schedule of major and minor releases.

Agile practices to plan and write stories

But where's the process rigor in getting stories written, reviewed, solutioned, and estimated? If your product owner or a business analyst is writing stories, when do they need to have stories completed so that teams are ready to execute on them?

In my book, Driving Digital, I detail an agile planning process that's prescriptive on how and when stories are created. I call it "agile planning" and if "agile development" is the process of getting stories implemented, then agile planning is a separate process that starts with ideas, concepts and features and ends as stories are fully written and estimated.

Basic concepts of agile planning

Here are some of the basic concepts in the Driving Digital Agile Planning Process

  • Features are first broken down to a list of "story stubs" which consist of the story summary but with little additional detail.

  • Stubs are always estimated - even though they are vague - to give the product owner feedback on complexity and to aid in deciding what is MVP for the feature.

  • Product owners or business analysts that write stories also "commit" to having stories fully written during an "agile planning sprint". The agile planning sprint often starts and ends 50% of the way into the agile development sprint which helps get stories fully written in time for the next agile development sprint. 

Benchmarks of healthy agile planning

Here are some benchmarks I look for teams practicing agile planning -
  • Stories for the upcoming agile development sprint are fully written by 50% of the way into the agile development sprint. Stories coming in later than this are marked as "late" as they pressure the team to review, size, and solution in less time.

  • I like to see at least 3+ sprints of story stubs in the backlog. 

  • I want healthy balance of stories - usually measured across a release of sprints and not a single sprint
  • 30% of stories coming from the agile planning process
  • 30% of stories reacting to developer, user or stakeholder feedback that is conceived during or at the end of the sprint. These stories can be anything the team reacts to as they are developing the product. They include stories that do not full achieve 'done' at the end of a sprint, user requirements that change, new use cases, or responding to newly identified risks. 
  • 30% technical debt
  • 10% spikes and R&D 

These numbers can be adjusted if the team has lower technical debt or reactive stories, but I like to see the 10% spikes/R&D increase proportionally under these circumstances.

Once stories are written, Driving Digital also provides a two-step process on estimating stories and how product owners can make best use of them.

continue reading "Benchmarks for Healthy Agile Planning that gets User Stories Written and Estimated"

Agile Development is like Running a Restaurant Kitchen [Video]

I had the opportunity to work with Infoworld on this video illustrating how agile development is a lot like running a restaurant.

Restaurants requires operational excellence to deliver high quality meals, excellent service, and on time delivery to restaurant patrons. They also require some creativity and innovation when developing new menu items and adjusting ingredients based on what's available. Lastly, running restaurants requires significant teamwork between "front office" staff tending to customer and "back office" cooks working to prepare the meal.

Restaurants leverage and sometimes develop their own technology to develop the product. Cooks have generalized skills like knife skills and specialized skills like baking. Kitchens have to be safe and clean to meet regulatory requirements. Sound like software development?

The video speaks to kanban and scrum processes, although it applies sprints to both which technically isn't correct. It speaks to the importance of retrospectives to improve process and using automation to make teams more efficient.

If you have a new team learning agile development, scrum, or kanban, then have them watch the video!

Learning about Agile Development and Scrum

Some of my other agile and scrum articles at Infoworld:

continue reading "Agile Development is like Running a Restaurant Kitchen [Video]"

The #1 Reason Why Digital Transformations Fail

Harvard Business Review just published why so many high profile digital transformations fail highlighting some of the difficulties several high profile programs. They reviewed digital transformations from GE, P&G, and Nike and suggest several lessons learned:

  1. "No managers should view digital — or any other major technological innovation — as their sure salvation."

  2. "It requires foundational investments in skills, projects, infrastructure, and, often, in cleaning up IT systems"

  3. "It’s important to calibrate your digital investments to the readiness of your industry — both customers and competitors"

  4. "The allure of digital can become all-consuming, causing executives to pay too much attention to the new and not enough to the old."
While I agree with all these points, I think HBR put too much emphasis in the wrong message to the average small, medium, and large business. Perhaps "high profile" digital transformation programs need to be evaluated differently.

The Real Reasons Why Digital Transformations Fail

IMHO, here's why many digital transformation programs fail - 
  1. Failure to start, either because there's a lack of leadership, leadership can't agree on strategic goals, or there are too many leaders vying for the top spot leading the digital transformation program.

  2. Leaders across the organization don't fully understand or underestimate the investment it requires to drive a digital organization.

  3. Executives don't invest enough attention in the digital transformation programs (in contrast to HBR's #4)

  4. Leaders, CEOs, and Boards still judge digital investments on 1-3 ROIs instead of 3-7 year transformations programs.
Let leave reason #0 aside. but I had to mention it. If you don't get a strategy and transformation program off the ground because of internal apathy on the need to change, or disagreements on strategy, or fighting on who or how the program should run, then you are already marching to failure and potentially business doom. Failure to start is still a failure and according to one study, 60% of organizations lack a transformation strategy.

And the #1 Reason Why Digital Transformations Fail

Assuming you get past the starting gun then ....
The number one reason digital transformations fail is because executives fail to embrace that it's a bottoms up transformation that will require change across the organization over a 3-7+ year period. Tweet: The number one reason digital transformations fail is because executives fail to embrace that it's a bottoms up transformation that will require change across the organization over a 3-7+ year period.
In other words, organizations that just focus on new business models, new technologies that drive competitive advantage, new digitally backed customer experiences, or becoming analytical and data driven are touching the initiatives that digital.
The heart of what makes transformation succeed is focusing on the people and process transformations and giving the organization, customers, and often the industry sufficient time to respond to the organization's digital initiatives.  Tweet: The heart of what makes #DigitalTransformation succeed is focusing on the people and process transformations and giving the organization, customers, and often the industry sufficient time to respond to the respond to the organization's digital initiatives. - @NYIke

Transformation Slowly Happens by Empowering Digitally Driven Leaders and Employees

To "succeed" at digital transformation, organizations need to focus on how they operate and consider how to enable employees to be more digitally driven. Here are some examples:
  1. Are your business teams taking on roles in agile programs or are you still looking for multi-month project plans? Or worse, is agile a technology process?

  2. Are your building digital experiences based on incremental feedback from the markets, customers, and non-customers? Or are your MVPs overloaded with everything everyone wants?

  3. Are you enabling a people first, learning, and experimenting environment or are you still throwing people under the best when something doesn't go as planned?
Successful transformation programs are about inspiring people - prospects, non-customers, customers, and especially employees on what your brand represents, how you deliver value and simplify things for customers, and how you inspire employees to drive the organization to new heights.

Maybe, we should be less concerned about the high profile failures.

continue reading "The #1 Reason Why Digital Transformations Fail"

6 Easy Ways to Lead Product Owners and Drive Meaningful MVPs

It isn't easy to put governance and guardrails on product managers and product owners. You trust them to engage customers and prospects across segments, capture needs from users of competitive products, and understand strategic requirements of internal stakeholders. You task them to develop product visions that deliver value and convenience to end users. You ask them to engage designers to develop winning customer experiences and you expect them to collaborate with technologists to seek out feasible solutions.

And then they sometimes come out with an MVP that is totally unrealistic to implement. In my last post, I shared 10 critical mistakes products owners make when developing MVPs and suggested that many of these mistakes occur because of inexperienced product owners or when there isn't any form of governance or guardrails in place to manage them.

Organizations investing in digital transformation programs that include customer facing application development need to think long term. Open investing in new products is important, but over engineering features, underinvesting in technical debt, or developing applications misaligned with the technology platform and architecture strategy will likely drive a new generation of legacy applications.

If you're a CIO or IT Leader, driving platforms is one of the things I stressed in my Driving Digital Transformation post, What should CIOs leading digital transformation focus on in year two and onward in the journey?

If you are a product owner, in  Chapter 6 of my book, Driving Digital, the Leader's Guide to Business Transformation Through Technology I provide more specific guidelines on how to develop and plan new products

Driving Product Owners to Meaningful MVPs

For this post, let me share six ways you can put some basic governance on product owners. Three of these help drive team alignment and the other three are operating metrics.

Driving MVPs

Product owner and team alignment

  1. Develop impact assessments of features developed - As product owners develop features, make sure they have mechanisms to measure their impact. Measuring impact is easier to do in ecommerce where you can capture customer journeys and sales, but it may take some creativity to understand in workflow applications. Even when measuring impact isn't a perfect science it can still lead to fruitful dialogs with product owners on the features they sponsored, the overall cost of the feature and the impacts they made with end users.  

  2. Bound product timelines by a defined release management strategy - A product owner often thinks of maximizing the value being delivered (often in features) for a target product release date that can be several months out from the start date. But the engineering team should already have standardized a release management strategy and the combined team should break down a product release into several engineering releases. Why? Well for one thing, the engineering team should be optimizing their cadence, velocity, and working practices to these release patterns so it's far more likely that the product owner will get a higher velocity and product quality by leveraging them. Second, the product owner should use these engineering releases as alpha or beta releases and test impacts with end users. It's a discipline that forces product owners to make sure high priority features work well before they prioritize secondary needs.

  3. Review go to market strategies for the prioritized features - The question here is whether the product owner has thought through how to market and operationalize the feature. To do this, it's a good idea to have a session where the product owner reviews a high level rollout plan with the implementation teams and where questions are encouraged. Asking for the development of features without plans, or when rollout plans are too big or complex are strong signs that the product owner is asking for too much. Similarly, the team may contribute new ideas to either simplify or enhance the user experience. Lastly, it's a good idea to find out why the product owner prioritized the features, what customers or end users will benefit from it, and what value proposition or need it addresses. All of these questions are designed to help narrow down the feature set to the ones most valuable.

Product owner backlog metrics

Driving Digital by Isaac Sacolick
Driving Digital -
Chapter 2: Agile Transformation
Chapter 6: Digital Products
  1. Account for technical debt and support issues - If you're giving product owners authority to prioritize 100% of a team's velocity (or multiple teams) then that may be a critical mistake. Teams should also be committing part of their velocity to address technical debt and support issues. I look for a rough allocation of 50% dedicated to technical debt and support issues and 50% to new capabilities. Even more powerful is when the priorities of technical debt issues are managed by the technical lead or architect, and support issues by an operational lead. They can then be held accountable to provide their own impact assessments (see point 1).  

  2. Challenge and limit the number of large stories - If you're estimating agile stories with story points then that provides a measure of both effort and complexity. Asking teams to deliver on a large number of high-point stories is a risk; either the product owner is asking the team to build features of high complexity, or the team is struggling understanding requirements, or the team is learning how to keep implementations simple within the selected technology platforms. Regardless of the reason, it's a good idea to question product owners and teams that have a larger number of high point stories scheduled for a release.

  3. Ensure there is a reasonably defined backlog - If product owners are finalizing stories just before the next sprint's commitment, then it can be challenging for teams to estimate and deliver on expected requirements. If you leverage my estimating methodologies (Chapter 2 of Driving Digital) , then I recommend the product owner have a backlog of at least two sprints of fully written stories (upcoming sprint plus one) and an additional two sprints of story stubs

Who should provide oversight on product owners?  

With some guidelines and governance, organizations need to consider who should oversee them. If there's a PMO, then providing this oversight is a natural extension of their responsibilities. In smaller organizations, CTO / CIO that have product responsibilities can provide the oversight. Otherwise, these oversights can be implemented in practices (for 1-3) and via metrics captured in tools (for 4-6). 
continue reading "6 Easy Ways to Lead Product Owners and Drive Meaningful MVPs"

10 Critical Mistakes Products Owners Make When Developing MVPs

Product Owner MVPs
Google was a search box. Yahoo was a directory. YouTube let you search and play videos. Many of the best applications started with humble beginnings, simple user experiences, and demonstrable value to end users.

So why is it that many product owners over engineer their minimally viable product with too many "must have' features, data integrations, user interfaces with an oversupply of bells and whistles, and other capabilities?

It's been seven years since I wrote this post on simple agile product development about the collaboration required to engineer non-complex products. I challenged product owners that try to develop a death star or a flux capacitor and answer why product owners should target minimal marketable feature sets and then add features incrementally. I've begged product developers to seek out user behavior data and market research to define and better prioritize their feature sets. I also wrote a post on rapidly planning product MVPs and a whole book on Driving Digital that has a chapter dedicated to product development and management.

Critical Mistakes when Developing Product MVPs

Yet I still see product managers making some common mistakes

  1. Taking the desires of stakeholders literally and funneling too many of them into the product.

  2. Failing to define customer segments, user personas, and user roles when designing the customer journeys. 

  3. Driving beautiful UIs instead of simple UXs and making MVPs overly complex to implement.

  4. Neglecting to ask end users questions (or asking the wrong questions) to help validate the value proposition and priority of new features.

  5. Forgetting how to use alpha, beta, A/B releases and other mechanisms to slowly introduce new UXs, design changes, and features incrementally by customer segment.

  6. Failing to engage the engineering team during the planning and development process to consider implementation complexities and alternative approaches that drive "good enough" results.

  7. Believing that "more is better" instead of "less, but implemented well is better".

  8. Underestimating the effort in developing automated tests while pushing for more functionality, more data elements, and more capabilities that require a greater investment in testing.

  9. Leaving non-functional requirements like performance criteria, what usage data to collect, and SEO requirements as "technical criteria" and expecting technologists to implement them with little business guidance or budgeted time to implement.

  10. Underspecifying business reporting, administrative tools and other "back office" functions that are important to manage related business functions.

I'll stop at ten. 

Establishing Product Development Guidelines and Guardrails 

Why does this happen? Why are we 20+ years into web development ~10 years into mobile app development and still seeing product owners making some of these common mistakes?

The simple answer is that many organizations have never truly managed product development, and the product management / product owner roles as a maturing discipline. Many feel lucky enough to have someone (or a few people) playing that role and therefore give them significant latitude to drive their products. There may be few training opportunities for new product owners and little oversight applied to more experienced ones. 

There are relatively few organizations that have simple product development frameworks. For organizations looking to make digital a core competency, a product development framework and governance model is needed.

continue reading "10 Critical Mistakes Products Owners Make When Developing MVPs"