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"

Don't write another line of code without reading this

Spaghetti Coders
Every once and awhile I get to review other people's code. One year it was 1.4 million lines of PERL code running a SaaS website developed in the late 1990s. There was another time that I ended the relationship with a BI vendor because the platform required several hundred lines of code to produce a very basic bar chart. I once reviewed a homegrown ERP developed with tens of thousands (and likely hundreds) as Oracle stored procedures. My absolute favorite was reviewing several dozen revenue driving applications built on top of Microsoft Access which led me to write the post asking (begging) friends to please stop creating them.

There comes a point where the terms "technical debt" and "legacy" don't do justice for code nightmares.  Tweet: There comes a point where the terms "technical debt" and "legacy application" don

When there's hundreds of thousands of lines of code - developed on any platform or language - that doesn't leverage frameworks, design patterns, logging, exception handling, code commenting and other software development principles. When there aren't architects setting standards, pair programming practices in place, or coder reviews instituted. When designers decide to mix business logic with presentations or when database developers elect to develop stored procedures to do everything.  When copy/paste is considered code reuse and when obsolete code is never removed from the repository. When there isn't a version control repository because this was supposed to be a small application.

I could go on...

Mind you I don't blame all of this on the developers that created the mess. Some didn't know better. Others weren't given the right platforms for the job at hand. Likely all of them were under time pressure to get thing done the best way they could.

Management is to blame for poor coding practices

Here's the real problem. Many organizations are doing a ton more coding today than they were a decade ago.

You aren't just building brochure-ware websites, you're building multi-device user experiences that connect with transactions and data from multiple enterprise systems. You're not just developing reports, you're instituting automation, dashboards, and other analytics that drive decision making. Many of you are developing APIs and microservices just like software companies.

All of you are under time pressure. Pressure to go beyond the MVP. Performance requirements. Regulatory requirements. Increased security and testing requirements.

What are you doing better today to develop quality software?

Today it's so much easier to write more and more code. You can get development environments with a credit card and a few clicks. You can search github and leverage one of the very many coding frameworks or open source libraries out there to ease development. Or you can use a lowcode platform.

There's demand for more applications and it's easy today to have applications with lots of code - whether you wrote it or just included it. My question is, what practices are you putting in to ensure your codebase is maintainable?

What your development practice requires

Here is my short list. Your development team needs a person responsible to be an architect who not only defines development standards, but finds ways to review and measure them periodically. Your development leads should be reporting technical debt at the end of every sprint and you should be prioritizing a sizable percent (I recommend 30%) of your velocity to address it.

Your development team should be estimating their agile stories, ideally in story points so that the complexity of the business requirements is reported back to product owners.

If you have developers that are lazy about documenting their code or implementing exception handling, logging, and unit testing then this needs to be addressed.

By the way, it's not just coding itself that can create problems. Watch out for bad behaviors from product owner and from technologists.

You need a QA practice and they need to be automating their tests.

You should be listening to your developers and they should be recommending tools, libraries, and frameworks, and services to implement the applications. But the key word here is recommending. Developers shouldn't have carte blanche to leverage any open source repo or integrate any cloud service they want based on their own expertise.

And you should be developing many more POCs before making the decision to leverage a new technology.

Lastly, if you're a CIO or a CDO and have never coded before, make sure you have one or more lieutenants who have this experience. You can always call me for help.

End rant.

continue reading "Don't write another line of code without reading this"

10 Reasons to Attend Technology Conferences

Last year I attended and spoke at over twenty (20) conferences that covered a wide range of topics from Artificial Intelligence to Agile & DevOps to Data Science.  I spoke on a wide range of digital transformation topics and had the opportunity to meet many interesting IT leaders and event sponsors.

There are lots of reasons to attend technology events so let me suggest some and how to get the most out of them -

  1. Open your mind to fresh thoughts and new ideas - IT leaders in the office are like deer in the headlights on an eight lane freeway. Tweet: IT leaders in the office are like deer in the headlights on an eight lane freeway. Getting out of the office a bit helps - @NYIke #CIO Getting out of the office a bit helps many IT leaders to clear their minds and see the forest from the trees.

  2. Networking with peers, potential hires, or new opportunities - Since you are all seeing and participating in the same agenda it's easy to meet and start conversations with new people. But make sure to follow up beyond just doing a LinkedIn connection in order to form lasting relationships.

  3. Identify new partners - Conferences are an efficient way to learn about new companies and products and see their capabilities in action. More importantly, you can discuss your business needs with them (and sometimes their customers if they are attending the conference) to gauge whether it's worth following up.

  4. Recognize that your not alone with your challenges and get help - Whenever I speak at conferences or moderate a panel, I'm always looking around the room at people's facial expressions for that look that says, "Damn, I have the same problem." Many of those people come speak to me afterward to discuss and often learn that they are not unique with these challenges. Some just look to vent, others find comfort that they are challenges are not unique, but many use the opportunity to solicit new ways to cope, improve, or solve their challenges.  

  5. See emerging technology in action - We all know that the media loves championing stories around emerging technology... And we also know that the path to leverage new tech is full of speed bumps, wrong turns and false starts. "There's no better place to hear and see new technology in action than at a tech conference whether its being demoed by a sponsor or being talked about at a session." Tweet: no better place to hear and see new technology in action than at a tech conference whether its being demoed by a sponsor or being talked about at a session. - @NYIke #CIO Even better is when you network with early adopters and can follow up with them after the show.

  6. Why just attend? Speak, or join a panel! - Even before authoring Driving Digital and starting StarCIO I was a frequent speaker and panelist at conferences. It gives you an opportunity to organize your learnings and generalize them to a large audience. It helps polish up your presentation and storytelling skills which are all critical for IT leaders today. It also makes it easier to meet new people when they approach you after the session with questions.

  7. Pick an analyst's brain - We love challenging, thought provoking questions. We also attend to share what we know so seeking analysts at conferences is a great way to get quick (and cheap) answers to your questions. 

  8. Brainstorm and innovate! - Don't just listen to the content being presented! Absorb it, ponder it, and let it help you generate some new ideas. You just may come up with that great next big startup idea when listening and learning.

  9. Share on social media and with your colleagues - In addition to meeting people attending the conference, posting what you learn on your social networking feeds is a great way to meet others sitting on the other side of the room and others not able to attend. Some of the best people I have "met" at conferences came through twitter dialogs. In addition, I always tell my staff to monitor my feeds to see what I'm learning in real time and then I would formally share key takeaways when I returned to the office. 

  10. Have some fun - Life is hard. Work is hard. Conference organizers know this and they all create opportunities to have some fun whether it's happy hours before meals, after hours in the tavern, other entertainment and especially poker nights.

continue reading "10 Reasons to Attend Technology Conferences"

What to do when the CIO still doesn’t “Get it”?

Clueless CIO
I was asked this question twice last year as a keynote speaker, one time by Chief Data Officers and the other by millenials working in marketing and other digital roles. Their sentiment was that their CIO was too slow to implement modernized digital platforms, hadn't instrumented collaborative practices, or was just perceived as a "no person" when presented with new ideas and needs.

Here's one of my answers and it comes from my book, Driving Digital: The Leader's Guide to Business Transformation Through Technology

If you are a technology leader and didn’t do some of these things, chances are you were replaced or will be soon. You will be disintermediated by spending too much effort just keeping the lights on instead of driving change or by being the business steward on risk instead of being a solution provider.

In the book, I provide more substance on what there things are and they include partnering with marketing on lead generation, leading data governance programs. and establishing agile development practices.

The people asking the question already had their answers. Some with more senior roles do their best to work around the CIO and IT to get what they need. Some of the millenials in the group seek out leaders and mentors who are willing to challenge the status quo and try to join their teams and programs. Those less empowered are more likely to put in their time, then look to leave and join more progressive organizations.

None of these options are very good for the organization or for the CIO. It demonstrates an underground movement of people capable of doing more, stifled without the support, and either working around it or working to leave it.

To my fellow CIO and IT leaders

Your world is bigger and faster than it ever was with new impacting technologies, faster practices, more significant strategic opportunities for technology driven change, and certainly more threats. You are being asked to do more with less, to grow the portfolio even though the legacy is shrinking slower, and to be an expert in all technology things climbing the Gartner Hype Cycle.

My simple advice is to get help.

StarCIO Implement Digital Strategy
You can't be an expert at everything, but you can bring in the help to accelerate your organization. If your slow to adopt agile practices, get help from coaches. If your data landscape looks like a landfill, then bring in experts that can kickoff data governance, consolidate data platforms, or automate data pipelines. If you don't have the funding to implement change, get help from technical financial analysts who can review vendors, assets, and workflows for cost optimizations.

Then, go out and work with both leaders and staff. Listen, listen some more, and learn. Go visit customers the big, the small, the happy, and the unsatisfied. Better yet, go visit those that are no longer customers or ones that have elected to work with a competitor. 

Then formulate how you can either lead or participate in your organization's transformation programs.

This is the final article of a multi-part series on What I Learned about Digital Transformation from Speaking to Hundreds of Leaders. You can read the previous articles on If data is the new oil, we’re still digging wells"We are more successful onboarding new technology versus maturing it"Financial Practices are Outdated for the Transformation Era - (And here's what you can do about it),  Developing a Strategy for Putting People First in Transformation Programs and We are doing agile but are not AgileSign up for my newsletter for even greater insights!

continue reading "What to do when the CIO still doesn’t “Get it”?"