Three Agile Management Practices for Driving Digital Transformation

When I joined Businessweek ten years ago to lead their digital technology team, I was very surprised that they wanted to develop their own proprietary web applications. Could a magazine owned by a publisher mature a software development practice and deliver new customer experiences?

The answer was yes - and as it turns out - many other companies are investing in their software development practices as part of their digital transformation programs. In many cases, the investment is driven by businesses needing to improve customer experiences with mobile and other capabilities. In other situations, businesses are looking to automate processes, become more data driven, or enable a strategic advantage with new capabilities in IoT, blockchain or artificial intelligence.

Whatever the driver, these IT departments are trying to operate like software companies and are highly likely to be establishing agile practices central to their transformation.

Teams, standups, demos, retrospectives, story writing, backlog grooming, sprint planning and other practices and tools follow. But are agile rituals sufficient to enable an agile culture or help drive transformation?

To enable transformation and enable an agile culture, organizations should consider the addition of the following  practices -



Aligning Product Management to Agile Delivery


A very common issue facing organizations looking to invest in application development occurs when agile is only applied to the delivery team (technologists) while product management participates only in tactical ways. They'll show up to to sprint planning to make sure their priorities are aligned and then to demos to review the deliverables. That may be the extent of the interaction. Now I've posted on the 20 bad behaviors of product owners and how to handle difficult product owners from many experiences working with product owners that don't fully align with agile practices. I've also suggested the 10 practices of strong product owners which center around market needs, collaborative behaviors, and being data driven.

The most common source of misalignment falls into two categories.

Some product owners propose solutions instead of defining the problem, aligning with personas, and articulating acceptance criteria. Their stories read, "Build me X that does Y" instead of "Enable user persona A to achieve B because it helps them address C if the solution can D, E, and F". No development teams prefer being told what to do instead of being engaged on what problem they are being asked to solve, for whom, for what benefit, and with what constraints.

The second misalignment occurs when product owners, often feeling the pressure from stakeholders, commit to specific deliverables and a delivery schedule without consulting the development team. The result boxes in the team (including the product manager) into a fixed timeline and fixed scope release cycle that may be difficult or impossible to achieve. Forecasting release schedules and scope must be solved collaboratively with an agile planning process which I will review in the next section.

But before we get there, the most troubling misalignment is when a product owner (or owners) have both issues. They commit to business schedules and then send marching orders to their delivery teams. Organizations that find these behaviors acceptable will never achieve an agile culture and will struggle to transform. In my experience, these divisions are not a "business IT alignment" issue, but speak to a larger leadership and cultural issue with how business leaders and business teams work with technologists.

What does alignment entail? Here are some suggestions

  • Developing roadmaps together (next section) 
  • Establishing brainstorming sessions so that business and tech leaders can collaborate on solutions
  • Documenting responsibilities by role
  • Enabling tech leaders to visit customers 
  • Aligning on usage metrics, other business value measures, and delivery metrics
  • Celebrating the wins


Estimating and Developing Delivery Roadmaps


Business doesn't operate on a sprint to sprint schedule or as a continuous delivery stream of product improvements. To enable Sales and Marketing to reach customers with new or enhanced products, or to enable business teams to plan process changes with the delivery of new internal technology capabilities, some semblance of a roadmap is required to enable business planning. Business leads are simply asking, "Roughly what are you developing and approximately when will you deliver it", a question that product owners struggle answering and development teams difficulty resolving.

Developing roadmaps and agile planning is a large subject of my book, Driving Digital: The Leader's Guide to Business Transformation Through Technology. In the book, I provide guidelines on establishing an agile planning process, defining roles and responsibilities in planning, developing estimates that can aid in defining MVPs, and establishing release roadmaps.

Want some background? See my previous posts on the 1-week agile planning sprint and on developing a release management strategy.

Leveraging DevOps and Enabling Developers to Continue to Innovate


Let's say you are successful with agile delivery and your teams have put out their initial products or applications. Maybe they've even released major and minor enhancements to these applications over a period of time. So here's my question
Are your development teams innovating and improving the product, or are they buried in technical debt, spend significant time supporting their cloud environments, or are largely performing support functions like defect fixing or implementing upgrades?
You can certainly measure this in your agile tool by tagging stories and tasks appropriately. If you haven't done this diligently, I highly recommend it as the results might surprise you. In my experience, the longer a development team works together on an application, the more likely they are taking on support related tasks and executing less innovation.

There are a couple of things leadership can do at this point, but the most important one is related to how much the team spends on supporting the application in the cloud and automating the CI/CD pipeline. If the team is spending a lot of time on these activities, then it may be time to make sure that there is the right separation of duties and handoffs with a DevOps team. IMHO, one reason developers should now own DevOps is that it is a significant responsibility and diverts their attentions from improving applications and innovating.

Why These Agile Practices Drive Digital Transformation


  • Aligning product management drives productivity around the most important customer opportunities
  • Developing delivery roadmaps builds confidence of business leaders that need to support investing in transformation programs
  • Leveraging DevOps is a step to break off support related activities so that top developers can continue innovating

continue reading "Three Agile Management Practices for Driving Digital Transformation"

Why YOU Should be Driving Digital!

On August 24th, my book Driving Digital: The Leader's Guide to Business Transformation Through Technology will be available!

You probably guessed that I would eventually author a book. The book covers some of the themes that I've covered here on Social, Agile, and Transformation including agile management, DevOps, architecture, portfolio management, data science, product management, and organizational culture. But unlike a blog, it provides a sequence that explains why these practices are important in implementing transform, what specific practices to mature, and how to go about leading them in your organization.

Why Driving Digital?


Driving Digital
Driving Digital:
The Leader's Guide to
Business Transformation
Through Technology
This journey began a few years ago when I was interviewed by Gil Press for an article that he would later title, 5 Things To Do When You Lead a Digital Transformation. At the time, I had just started hearing about digital transformation and quickly realized it's something that I had been working on almost my entire career starting with the newspaper SaaS company that I joined in the late '90s. 
My career took me to be CIO at several different organizations that were facing disruption and required evolving the product set to address new market needs. What I learned is that organizations require a fundamentally new set of practices and capabilities to drive digital and enable a smarter and faster business transformation.

These topics are covered in the book's chapters - 
  1. The Transformation Imperative
  2. Agile Transformational Practices
  3. Technical Foundations for Transformation
  4. Agile Portfolio Management
  5. Transforming to a Data-Driven Organization
  6. Driving Revenue Through Digital Products
  7. Driving Digital: Smarter and Faster
Why digital? Here's what happened to newspapers, here's what industries are most likely to be disrupted by digital and here's why digital business capabilities can cause industry disruption. Most businesses require a digital strategy and plan to rebuild their digital businesses or face some form level of disruption.  

My book takes you on a "bottoms up" journey, starting with fundamental agile transformational practices and ending with more strategic capabilities like digital strategy, product development, product marketing and organizational culture.


Why YOU should be Driving Digital!


Digital transformation requires leadership at all levels. If you're the CEO, you need to embrace a strategy and realign the leadership team. If you're a CIO, CTO, or CDO (Digital or Data), you have a large number of practices to enable that drive transformation. If you're the CMO, you need new ways to prioritize customer segments and to experiment with digital marketing to reach them.

But digital transformation is not just about C-level leadership!

If you're a developer, you should understand how to improve agile practices so that thecan align with digital strategy and execute product roadmaps. If you're a data scientist you should be establishing practices that enable a data driven organization. If you were an engineer in the data center and now overseeing cloud infrastructure, you have to be enabling DevOps practices to automate and scale. If you're a product manager, you have to help connect digital strategy to product roadmaps and deliver product enhancements that wow customers. If you are a marketer, an operations manager, or a financial analyst - all your practices are likely to have growing importance but changing practices and technologies as digital becomes a more significant business driver.


What's Next in Driving Digital


It doesn't end with the book. Over the next several weeks on this blog, I'll be sharing new insights on DevOps, CIO leadership, and many other topics introduced in the book. I'll be speaking on many topics this fall, and sharing new insights on my blog at CIO.com, Driving Digital Transformation.

I hope to hear from you on your thoughts and questions! - find me as @NYIke, sign up for the digital transformation newsletter, or contact StarCIO.

continue reading "Why YOU Should be Driving Digital!"

5 Things CIO Should do this Summer

Take a step back - it's summer time. You may not be able to slow down, but you should have more opportunities to do things outside of the normal day to day and monthly grind. If you do, consider the following options -

  1. Unplug - My advice for CIO on taking summer vacations includes unplugging from email, learning something new, and setting priorities on your time. Consider using the time to catch up some reading. Later this summer, my book Driving Digital: The Leader's Guide to Business Transformation Through Technology will be available and there is also CIO Insight's list of summer books

  2. Develop a new business relationship - CIO leading transformation efforts need partners and collaborators to lead programs. Summer is good time to select someone new in the organization and develop a meaningful relationship. For example, if you haven't done this already, here are my tips on starting a killer relationship with the CMO.

  3. Have fun with your team - Transformation programs require a lot of hard stressful work and summer is a good point to bring fun back into the IT culture. My favorite department activity is to host a summer pot-luck picnic or barbecue.

  4. Schedule fall events - Before your Q4 calendar gets overfilled with meetings and tasks, consider scheduling some time out of the office to attend a conference. Here's my dashboard of upcoming events for CIO, CTO, Chief Digital Officers, and Chief Data Officers.

  5. Get hands on - If you have the time, nothing beats rolling up the sleeves to learn a new technology. At minimum, you'll get some insights on how the technology functions and what you can accomplish with limited time and training. You'll certainly get a better appreciation for your staff who often have to figure things out on their own. For example, here are some of my DevOps and cloud lessons after setting up a personal AWS environment.

Happy Summer!


continue reading "5 Things CIO Should do this Summer"

My Most Challenging Tech Presentation Was to Middle School Teenagers

I've been to several conferences the last few months sharing my insights on digital transformation, agile culture, and enabling the data driven organization - all key practices that I cover in my book, Driving Digital: The Leader's Guide to Business Transformation Through Technology. I've done long tutorials, fast TED-like keynotes, moderated panels, and participated in webinars all with different challenges in connecting to the audience and delivering insightful messages.

So when I was asked to present to 8th Graders at the Robert A. Van Wyck Middle School 217 in Jamaica, New York I jumped at the opportunity. My goal was to get them interested in STEM and hopefully enlighten them that a STEM education can lead to a challenging and rewarding career.

I was prepared knowing that talking to sixty young teenagers in two thirty minutes sessions and keeping them engaged was going to be a challenge. I started with a briefing on who I was, my background, and what CIO do at corporations. As excited as I am about my accomplishments, I knew this would not peak their interest.

So I elected to share some pictures with them. First, I shared charts from the Department of Labor on job growth projections for 2024 (roughly when this group may graduate from college) and other metrics on salaries of STEM graduates. I then selected my top five technologies that will still be important ten years from now. Two were technologies that I believed they would have some familiarity on (self-driving cars and wearables) and the other three were somewhat new to them (artificial intelligence, smart cities, and digital health).

Now Here's What I Didn't Expect


From the opening minutes I was barraged with questions of all types. Some were personal, "How much money did you make when you graduated and how much do you make now?" Others were inquisitive, "What should we be doing now to be ready for a career in computer science?" Many were thinking several steps ahead asking questions like, "Can we develop devices that will connect to our brains to make us super intelligent?" There was a flood of questions, one after the other, and the group often cut my answers off to ask their next question. Many of them were very good questions, and although it was difficult to control a classroom of excited teenagers, I was happy to see young minds thinking out loud and challenging the status quo.

I should point out that there were some in the group that were silent and clearly overwhelmed by all the questions their friends were asking. Many of them were girls, and I had to help bring them into the conversation. They were brilliant, asking questions on the impact of design on technology or about what life will be like when self-driving cars are widely available. Two girls asked me about how a STEM background would help them become architects one day. Another showed me a book of her drawings and wanted to know what types of work she could do in technology.

I asked the group how many knew how to code and I was floored when about half of them raised their hands. Several students asked me about programming languages and wanted to know whether they should learn ruby, php, or java. I thought to myself, "Wow! This is awesome," recognizing how important it is for younger kids to learn how to code.

The Unfortunate Side of Tech for Teens


Tech is everywhere for these kids, but what they get exposed to isn't going to significantly help them in their careers. Playing video games, watching videos, texting, and shopping are their day to day technology experiences while basic math, science, history and language consume them academically. The gap from basic high school education and the technology that's being implemented in new technology backed products or that run enterprises is significant. Kids interested in STEM have a tall order to fill that gap if we're to be successful innovating beyond today's capabilities.

So here's the advice I shared with these students:


  1. Develop your communication skills; writing, listening, presenting
  2. Learn to code
  3. Math, more math, and even more math
  4. Ask questions, challenge assumptions, and learn to be “data driven”
  5. Create something 


I'm glad I spoke to them and would gladly do it again!

continue reading "My Most Challenging Tech Presentation Was to Middle School Teenagers"

Driving Digital Tutorial: Branching and Release Management in GitHub

DevOps Git Branching
What's the number one software development practice needed by organizations committed to agile delivery of application releases that delight customers? My answer is version control with branching capabilities and tagging releases.

Is it number one? No need to debate whether version control is number one, top five etc. Most developers, testers, managers, and CTO will agree that version control practices are important to enable collaboration between developers, foster reliable application releases, establish process for different types of development tasks, and key to scaling the development practice. 

Branching enables Agile Development


I've worked with several development teams the last few months that are using GitHub but hadn't defined a practice for branching or tagging releases. How do you create a handoff from developers to QA? How do you facilitate a hotfix in production? How should you support larger feature development in parallel to small enhancements? How do you track releases and enable rollbacks?

While some of these procedures are straightforward, CTO and development managers often lack documentation to help large teams practice these steps in uniform ways. What results is a mess of branches, some developers branching while others not, formal releases but informal hotfixes etc. 

Then there are some strategic questions:

  • When should you implement a hotfix and what is the impact of taking on this emergency release
  • When developing a large feature, should you branch once for main feature or create multiple branches for each components? 
  • How should QA teams handle feature and hotfix branches?

Tutorial: Branching with Github


I've taken steps to answer some of these questions in a new Driving Digital tutorial, Branching with GitHub. It lays out steps to do many of the basic steps. It outlines roles and responsibilities showing who should branch, who generates pull requests, who merges and who tags releases. Lastly, it illustrates some of the tradeoffs when considering hotfixes and feature branching.

Sign up - Free Tutorial

I've put this in a simple free tutorial that you can receive. Just start by signing up, authenticate your email, and you'll receive a copy of tutorial.
continue reading "Driving Digital Tutorial: Branching and Release Management in GitHub"

Leveraging Data to Improve Customer Experience

Driving Digital with Data
Let’s consider a very typical digital opportunity. A company has a website enabling customers to log in, view recent activity, execute new transactions, and learn about new opportunities. The CMO wants to upgrade the site to improve the mobile experience and to introduce new analytics that she believes will drive increased usage and larger transactions. She comes to the CIO to partner on the implementation.

What first step should the CIO do when considering this opportunity? Should the CIO seek a business case on how much new revenue this investment will enable? Should IT leaders review existing platforms and consider the best technologies to rebuild? How about establishing requirements or designing the new customer experience?

My answer is none of the above.

What Does the Data Say?


The first thing the transformational CIO should do is to partner with the CMO and go on a data gathering exercise. Pull web analytics data to get sessions, pages, events, devices, and customer journeys. Merge in data from the commerce engine to capture transactions and data from the CRM on customer demographics. Lastly integrate the CMO’s market research on customer satisfaction and qualitative feedback on new capabilities and improvements mentioned by customers. Analyze this data by customer persona, spending behavior, and other dimensions to provide a data-driven story on the gaps and opportunities in a digital transformation of this website. This can then guide the business plan, customer experience, technology choices, and development priorities in the implementation.

Digital transformation affects every industry. It’s how banks must review online retail banking experiences, manufacturers their B2B ecommerce portals, insurance companies their tools for tracking claims, charities their websites for capturing donations, and hospitals their kiosks for providing patient information. Reviewing existing data, merging in new sources, and leveraging customer research is at the heart of delivering transformational digital experiences.

A Recipe for Becoming Data Driven


I cover many of the steps on becoming data driven in my book, Driving Digital: The Leader’s Guide to Business Transformation Through Technology. CIO can start with citizen data science programs that enable analysts in and out of IT to blend data sources, perform ad hoc analysis, and develop dashboards to share analytics and insights. The CIO should also be leading efforts to integrate enterprise data sources, so in my example above, data from the CRM, web analytics, and commerce engines should already be integrated and available as a data service to the analyst.

What happens next? With easy to use tools and access to data, analysts begin to ask questions and seek insights. As they analyze and expose more data, they are likely to hit data quality speed bumps such as duplicate records that need to be merged, inconsistent address formats, or records that are difficult to join because of inconsistent company names. CIOs can take the next leadership step by defining data governance, establishing master data sources, and providing tools to improve data quality.

Real competitive differentiation is when the CIO can leverage the CMO’s market research to provide insights into future needs. Market research may come in the form of survey responses, customer feedback, insights extracted from social media feeds, aggregated news, economic forecasts, and government data. In other words, a lot of unstructured data and forecasting data that can be challenging to integrate with existing enterprise data sources. The data wrangling can be complex, and new tools such as Claire are driving boosts in productivity by leveraging AI and machine learning to automate data management tasks and identify patterns in unstructured data.

Transformation by Leveraging Data


To enable digital transformation and growth, leaders today must look beyond their current capabilities and develop competitive customer experiences. Leveraging data, analytics, and research allows leaders to make well informed decisions on strategy, priorities, design, and implementation. CIO’s need to lead this charge by merging existing and new data sources and developing a customer-centric view exposing their values, needs, and opportunities.

This post is brought to you by Informatica and IDG.

The views and opinions expressed herein are those of the author and do not necessarily represent the views and opinions of Informatica.

continue reading "Leveraging Data to Improve Customer Experience"

Understanding the Basics of Deep Learning and Neural Networks

Last week I had the opportunity to visit my graduate school alma mater, The University of Arizona where I studied artificial intelligence and image processing many years ago. I remember signing up for my first semester classes and electing to challenge myself with Professor Neifeld's neural network class. It already had the reputation of being one of the toughest classes requiring students to understand both the mathematical theory and real-world application of neural networks to solve classification and other problems.

Neural Networks Before Cloud Computing


Of course back then there wasn't cloud computing or easy access to parallel computing methods or deep learning Python libraries. As students, we had to program the algorithms by hand starting with the mathematics of a single neuron, the iterations to loop through all the neurons in each layer, and the algorithms to implement the backpropagation learning algorithms. You were more likely to screw up programming the mathematics before even having had the chance to tune the network properly to solve the challenge.

Needless to say, I learned how to program many neural networks. I assumed when one failed, it was because I had selected the wrong algorithm rather than a flawed implementation.

The reason we have deep learning today is because cloud computing enables us to program multiple layers of thousands of neurons. And instead of programming the intricacies of the algorithms, AI developers are more focussed on how to present  datasets to AI algorithms, selecting algorithms, tuning the learning algorithms, and evaluating the behaviors.

A Simple Explanation of Neural Networks


But as an "old dog" of neural networks, it gives me the opportunity to explain what they are in semi-layman's terms.

Remember linear regression? You applied an algorithm to optimize the linear equation y = mx + b given a dataset of x and y values. Neural networks operate on a similar principle but are nonlinear and approximate a complex curve to fit multidimensional data. In other words, the main differences is that the simple linear regression model is working with one dependent and one independent variable (x and y) to determine slope and intercept (m and b) while neural networks can have many thousands of inputs (like an image), usually a few outputs (is the image a cat?) and can approximate highly complex, multi-dimensional surfaces depending on the number neurons and topology (number of layers) of the network.

How does the network work? Each neuron operates like a transistor with an activation function that dictates its output given a set of inputs. When the network is presented with an input, the first layer of neurons compute their output and feedforward them to the next layer. This is repeated until all layers of the network are computed and the final layer shares its result.

Of course the initial result is likely to be wrong and the network has to be tuned. Given a dataset of known inputs and outputs, backpropagation is one of the many "learning" algorithms used to tune the neurons (adjust their activation functions) so that the network outputs the correct values for the inputs.

If you programmed the network by hand, you'd have to sequence through all the layers of the network and all the neurons in each later to compute their activation functions, capture outputs, and arrive at the network's output. You'd then have to compute the backpropagation algorithm and apply iteratively for every datapoint in your training set. So while the code was relatively straightforward, the computation was very slow and inefficient. Cloud computing and parallel computing models solves this issue.

Neural Networks Today


Of course today, it's unlikely that a programmer or data scientist would be programming the model by hand as there are many libraries and APIs that have these services available. The researcher still has to pick the topology of the network, activation functions, learning algorithm, and other parameters. More importantly, the trainer has to select a way to present the problem set to the network (the inputs and outputs) and identify appropriate training and test datasets.

And that's just one example of "supervised" learning where there is a training set that can be used to teach the network, There is a whole class of unsupervised learning where the network is trained based on the quality of its response.

So while cloud computing and the availability of deep learning APIs has made neural networks available to the masses, it's still not a straightforward undertaking. AI still requires significant investment in agile experimentation to test approaches, validate conclusions, and configure the next set of experiments.

But the results are impressive and many companies with strategic datasets are exploring the science and business value of deep learning. Just in the news the last few weeks - measuring store visits, sports analytics, healthcare research including diagnosing cancer, and even beekeeping. With a forecast to grow to $10.2B by 2025, I suspect we'll see a lot more investment and experimentation over the next several years.  

continue reading "Understanding the Basics of Deep Learning and Neural Networks"
Share