TEMPLATE ERROR: Invalid expression

Is Leadership Ready to Handle a Shark Attack?

CIO and IT leaders should be able to relate to this video. Watch the first few minutes to see Mick Fanning waiting to catch a wave when suddenly he is attacked by a shark. You can see him scramble a bit then fend him off before a boat comes to his rescue.

Now for those of us in IT, there are some great lessons to share with your business leaders on handling a real life crisis from this video.

  • The announcer shows no real sign of panic. Yes, he utters a cuss word when he realizes what's going on but he regains his composure and shows no panic or stress in his reporting despite the fact this has rarely (if ever) happened before.

  • There are clear operational procedures for this type of crisis and within minutes, you can see two boats zooming in to help with the rescue.

  • There are also safety and communication procedures outlined on what to do and the commissioner of the event is bound to follow them. 

  • The shark gets away which unfortunately is more often to happen in the corporate setting when a business leader goes on the attack.

Unfortunately, I think many CIO can reflect on this situation. Does your leadership team panic at the first sign of a major issue or crisis? Are you well prepared to handle the crisis with clearly defined operational procedures? Are you ready to handle communications during and after the crisis? If the issue is internal, do you have a culture that deals with individuals that are the source of the crisis?

continue reading "Is Leadership Ready to Handle a Shark Attack?"

10 Practices of Strong Agile Product Owners

I've worked with some excellent agile product owners that have developed new products, delighted customers, grown revenue, and collaborated well with their agile teams. I've also worked with other product owners that have some very bad behaviors reflecting in poor under performing products and angry team members.

So I thought to share some of the behaviors and practices that make product owners successful. They fall in three categories; understanding customer value, practicing agile, and leading data driven practices.

Customer Value + Agile + Data Driven

  1. They develop a holistic view of market segments, customer needs, and value proposition - Sounds like a 101, but many product owners dive right into developing solutions without developing segments, personas, and values as a guide.

  2. They are great listeners and collaborators - The best product owners know they are sitting in the center of a virtual circle between sales, marketing, technology and other stakeholders that have different opinions and skills. The best product owners listen first and collaborate with the team on priorities and solutions.

  3. Leverage agile strategically to shape their product to market need -  They capture customer feedback and use it to reshape their vision, requirements and priorities. They pivot when required and experiment to see what's working. 

  4. Sell their vision, detail their stories - Great product owners have to be excellent communicators to get larger teams to understand and follow their vision. They also have to be strong practitioners, best demonstrated by making sure the active agile stories are precise on what is required.

  5. Leverage a network of key customers and prospects - Great product owners develop these networks to get insight into the industry, test ideas, pilot new capabilities, or capture critical performance feedback.

  6. Partner with technologists on platforms, standards, and prototypes - Every organization develops standards to be efficient and leverage skills and investments. The best product owners learn to leverage these to their advantage by reapplying existing capabilities to accelerate speed to market rather than developing new solutions from the ground up. And when new capabilities are needed, they partner with technologists to develop prototypes to validate and gain consensus on approach.

  7. Review financial performance and contracts - Great product owners understand the fundamental financial performance of their products, profitability of key customers, health of the sales pipeline and other performance metrics. They also review customer contracts in order to make sure their requirements can be met. 

  8. Develop KPIs and use them to drive priorities - Product Owners need to insure their teams are data driven in their decision making. Their role is to define key KPIs on the products performance in areas such as financial, customer satisfaction, risk and other criteria to help drive priorities.

  9. Develop brands, platforms, and ecosystems - Winning at digital business requires product owners to recognize that products do not survive in silos. They need to consider how their offering might evolve to become a platform or interface into appropriate ecosystems. They must also partner with marketing to build brand, attract prospects, and develop relationships. 

  10. They balance priorities to short and long term needs - Product owners have the tough job of digesting all the issues, wants, and needs demanded by top customers and sales people, the technical debt and other system priorities escalated by their technologists, branding and messaging ideas escalated by their marketing professionals into a manageable prioritized list. Then comes the harder part of determining how to best balance these needs against the strategic vision and long term success drivers. 

And here's an extra one - one that many product owners under the stress of market conditions, difficult customers, challenging stakeholders, engineering realities often forget -

  1. They celebrate small wins and thank the team - Things go wrong all the time and the team is never truly 'done' with everything that customers need and product owners want to deliver. Great product owners know how and when to thank the team and individuals on accomplishments both big and small.

continue reading "10 Practices of Strong Agile Product Owners"

Where are you Implementing your Big Data Algorithms?

It sounds like a simple question. You have to load several data sets, implement some data cleansing, perform some matching to third party data, compute several aggregates, develop some rankings, group several dimensions, benchmark against another data set, analyze for trends and then normalize the data for multiple data visualizations.

In all likelihood, the algorithms that perform these functions are going to be implemented by different people in different technologies and perhaps at different stages in the analysis. End to end, they represent a complex data flow from data sources, computations, analysis, and delivery.

Key Data Architecture Considerations

So my question is, where are you implementing these data processing functions? Where are your algorithms stored? How are they documented? How do you answer questions around, "Where should I do this data processing?" What is your big data culture - Are you more likely to let data scientists determine what tool to use for different needs, or are you centralizing these data architecture decisions?

Once implemented, how do you review to determine what parts of your data processing needs to be refactored? Maybe a step isn't performing well? Maybe a data visualization required some last mile data cleansing that should be moved upstream to benefit other analysis? Perhaps some algorithm fails to meet the "KT" (Knowledge Transfer) test and is so complex it will be impossible to be maintained?

Or maybe, you've implemented something in a Big Data tool that has just released a major upgrade requiring substantial changes to the implementation? Or even worse, perhaps the tool you selected is on the downside, having never achieved critical mass and now you have to explore alternatives and consider switching costs.

The reverse question is equally important. Perhaps you're bundling some activity in the wrong tool and should consider expanding your technical architecture? Perhaps you are spending too many cycles getting SQL to perform and should consider a NoSQL store? Maybe the Python scripts you developed for data integration are becoming unmanageable and an ETL tool is needed?

Managing the Evolving Big Data Landscape and Growing Business Need

So the business need is growing, the technology landscape is changing, quickly, access to talent is volatile, and both standards and best practices are evolving. What does this mean for Big Data specialists and Digital Transformation leaders who need to prove results today but manage to an evolving practice?

My simple answer is to rely on the basic practices that have made application development practices evolve through significant changes in demand, technologies, and development practices. Some specifics -

  • Invest in basic version control so that you can track changed implementations  across platforms and practices.

  • Evolve a data governance practice that starts with basic data dictionaries and documentation on algorithms.

  • Build an agile data practice to make sure participants focus on the problems of highest business value and demo their results

  • Develop operational KPIs covering development cost, implementation complexity and system performance to sense when an implementation shows signs of becoming a pain point.

  • Capture technical debt data quality barriers and other things that need improvement.

And most important:

  • Invest time/resources to perform R&D and experiment.

Thanks to Matt Turck: Is Big Data Still a Thing
continue reading "Where are you Implementing your Big Data Algorithms?"

How to Kick Off a Citizen Data Science Program

Big Data Scientists
Citizen data scientists is catching on. Perhaps your organization can't hire or retain fully skilled and trained data scientists because of the skill shortage and the increasing salaries top talent command. Or perhaps you believe in the democratizing of data and that business analysts that were once influenced to become spreadsheet jockeys just need to be retooled with new data visualization skills and data governance principles.

Either are strong rationale to rethink how to transform the people, practices and technologies around your internal enterprise data and to take steps to drive a data driven culture.

Getting Started with Citizen Data Science Programs

So here are some tips on how to getting a citizen data science program started:

  1. Find a handful of underserved business units or operational groups that desire to be more data driven but are lacking the tools or practices, This can easily be the marketing department that needs to be more data driven to define segments and process leads. It could be the sales department that needs better reporting to drive sales management practices or the finance department that are under pressure to slice/dice P/Ls in new ways at greater frequency. 

  2. Cultivate a relationship with these business leaders to insure they are ready to take on a transformational challenge. If they are not ready to participate and sponsor this initiative it will fall short when you need to engage their resources to become citizen data scientists or you need their sponsorship to promote organizational change on leveraging any new data tools. 

  3. Find the data super users that are currently doing data work manually. These may be users that are skilled at asking good data questions, are very hands on with spreadsheets, or elect to use database tools that drive data silos. They may also be versatile running analytics in specialty tools like CRM, web analytics, or even ERP. These users have skills, but need technical direction on which tools the organization wants to support long term. They also need defined data governance practices to help avoid a new generation of data landfills.

  4. Define standards that can be developed incrementally but insure a scalable set of organizational practices. What data visualization tools will be used? What tools will be used for modeling? How do you separate what's in "development" vs. testing vs. ready to be used in decision making? Where are data dictionaries maintained? How is data access established? These are some of the new data management practices IT needs to help support and that citizen data science teams need to practice.  

  5. Define an agile data practice that provides citizen data scientists a prioritized list of problems to solve, a delivery practice based on agile principles, and assigns roles/responsibilities in developing solutions. By way of example, here is a practice defined to help find nuggets in an organization's dark data using an agile data mining process. The idea is to make sure there is a disciplined cadence that defines priorities, drives citizen data sciences to commit to completing an analysis in a fixed duration, and insures results are presented before moving onto new challenges.

continue reading "How to Kick Off a Citizen Data Science Program"

Stop! Don't Let Your Business Fall off the Digital Disruption Cliff

Have you ever seen the industry you're working in walk off a digital cliff? I have, and let me tell you it isn't pretty and it happens fast.

Once an industry begins transforming to a digital business with digital only competitors, incumbents have to move early, quickly and intelligently through a digital transformation. These businesses have to bring in new talent, invest in digital capabilities, and leave sacred cows behind in order to compete with digital disruptors.

Newspaper Ad Revenue 1950-2012

The figure shown here is what happened and continues to happen to the newspaper industry where the digital transformation started as soon as the internet became mainstream in the 1990s. The startup I joined and later became CTO of partnered with newspapers to help them go from "print to web" as the transformation was called back then in media. We started with a classified ad platform with natural language processing, a search engine, and a pre-CSS publishing engine that enabled us to aggregate classified ads from ~1600 newspapers and deliver a SaaS (back then it was called an ASP) product that enabled searching classified ads on the newspaper website. Over the next decade we built, merged and acquired capabilities to help run all the digital capabilities newspapers required including publishing content, hosting job boards, integrating with auto dealer web sites, and running a digital newspaper ad network. By 2002 we had eleven newspaper companies investing and using our platforms.

The Impact of Digital Disruption

But most of you know the other side of the story. Craigslist, ebay, cars.com, monster.com, hot jobs, realtor.com, yahoo, aol and countless others that saw the paper driven, inefficient, local newspaper as a slow fat target. Newspaper revenue grew in 1996-2001 during the bubble but fell off a sharp cliff when it burst? Why? Simply because consumers and advertisers had lower cost and higher value options and the branding, localization, and trust newspapers heralded wasn't sufficient to retain loyal customers.

Once digital alternatives appear in market, things go downhill fast for incumbents. While digital players learned how to compete digitally and improve user experiences, newspapers had to adjust their operating models and philosophies. Hours invested by newspapers to preserve editorial excellence, transform manual processes, or consider print/digital subscription models came in lieu of the hours invested by digital companies to improve customer experiences, steal market share, develop analytics, or automate processes aimed at growing revenue profitably. That transformational gap, along with drastically different digital pricing creates the steep fall off in revenue.

But that was Media, It Can't Happen In...

If you're naive to think this is a media phenomena then think again. I shared a number of other examples in my post, What is Digital Business and Digital Transformation. HBR recently reviewed results of a Russell Reynolds Associates survey of industries where executives anticipate moderate or massive digital disruption and while Media was number one on the list, it is quickly followed by telecom, consumer financial services, retail, technology, insurance, and consumer products. Basically, any product or service that can have differentiating capabilities via digital transactions, digitally enriched products (content, data, and IoT), multimode or omnichannel customer experiences, algorithmic or AI driven automation are likely to experience some form of disruption.

I'll let the experts predict which industries will be disrupted, whether they will be moderate or massive, when will they kick in and how fast they will transform. I will continue to share what to do about it.

Further reading on Digital Transformation

continue reading "Stop! Don't Let Your Business Fall off the Digital Disruption Cliff"

Is Your Data Ready for Digital Transformation?

Three really good reads this week if data or marketing transformations are elements of your overall digital transformation.

Enough Marketing Technology, not Sufficient Integration

Marketing Technology Landscape
Chiefmartec produced his annual state of marketing technologies showing an explosive growth in the number of vendors. I blogged about this last year to illustrate that the CMO and CIO should partner to help select the optimal technologies, but when I look at this year's landscape and almost another 2x of technologies that are eligible go be on the CMO's shopping list, it's the integration landscape that scares me. Trying to implements several of these solutions can be the Achilles heel of having an end to end platform that enables transformation.

Any volunteers to map out and rate the integration matrix? Implement it poorly and you'll have a 3874 x 3874 grid that will make a very ugly visual. 

Data Integration and Quality Made The Bottom Of This Big Data List

Review the top Big Data Technologies from Gil Press and you'll notice that the sexier big data, nosql, search, analytics, data visualization, and other analysis or delivery oriented technologies occupy the top positions while integration, data preparation and data quality fill in the bottom ones. I suppose there is some success that these less exciting data platforms made the list at all, but it got me thinking, "How many organizations have implemented all the analytics and data visualization without considering data quality or insuring robust automation in data integration?" Another question, "How many IT departments have provided robust self-service BI and data visualization capabilities with limited services around data integration and preparation?"

One thing that I've learned across several big data and data science initiatives is that the more data discovery and analytics capabilities you enable, the more data you expose to a larger number of people (including customers), the more likely you'll expose data quality issues and the need to automate data integration. I would suggest CDO, CIO and other digital leaders balance their investments and include more of these technologies and services in big data programs.

Citizen Data Scientists to Enable the Enterprise

Lastly, Myles Suer discusses the concept of citizen data scientists as way to fill the talent gap many organizations have in analyzing and processing their data. Myles describes the personas of data scientists as Explorers and Miners that are poorly enabled by data warehouses and BI technologies of the last decade because of the structures they impose.
With miners and explorers, we can enable safe collaboration at the front end of the business intelligence process, and use their collective efforts to lower costs while increasing the business relevance of anything they measure. This is a big opportunity 
Success comes by enabling these data scientists and emerging ones to be successful while balancing their data access based on security, privacy, regulatory, and other governance.

My experience is that more CIO and organizations are open to self service practices, but some of the tool providers have fallen behind enabling these scientists and developers.Are these platforms easy to learn? Do they enable version control, code reuse, and deployment practices?

Digital Transformation and Data Management

CMOs getting enabled, new data analytics capabilities, and new talent - but the underlying data management practices around integration, automation, quality, virtualization, preparation fall behind? These practices need attention to fully enable digital transformation.
continue reading "Is Your Data Ready for Digital Transformation?"

10 Best Practices in Configuring your Agile Project Management Tools

Scrum Board
If you are serious about agile development then you most likely selected a tool to enable team collaboration and manage the backlog, sprints, and releases. While I have heard of some teams and even organizations staying low tech and using stickies, cards, or spreadsheets, it's really hard to scale to multiple teams, manage distributed teams, or develop metrics to support process improvements without an agile tool in place that is configured to match the practice.

I am not here to preach one tool over another and have experience using different products over my last three agile transformations.  However, I believe that whatever tool you select needs to be configured properly to match the release cycle, sprint schedule, and other practice standards. While the agile practices that I have used across three companies have slightly different mechanics to match the specific business needs, there are several best practices that I can recommend to everyone

  1. One team, one backlog - This seems obvious but can become more difficult when there are multiple product owners for different products that need to be fulfilled by the same team. Another issue is when resources with specialized skills are needed part time across multiple teams. While there are different ways to handle these issues from a process standpoint, it is often better to configure agile tools to handle the basics. Agile tools help teams commit and report on team productivity, so it's best to configure them so that the team operates off a single backlog. So for multiple product owners but one team, implement one backlog.

  2. Backlogs must contain all work - There is one school of thought that the backlog should only contain Stories that embody product requirements. This is a purist viewpoint that keeps out other responsibilities and tasks outside the scope of the tool and potentially gives the team a false readout on velocity. A best practice is to include all commitments in the backlog and use the tools configuration options to represent them. For example, use Story Types in Jira to represent Feature Estimation, Decisions, Meeting Notes, and Tasks. 

  3. Normalize to a fixed capacity - Some tools enable you to record when resources are unavailable or only partially assigned to a specific team, while others don't have this capability. If you're going to track and improve team velocity, then learn how to use the tool you have to manage when resources are on vacation or unavailable. For tools that don't have this capability, a cheap option is to account for the missing capacity directly on the backlog so that out of office time is scheduled directly in the sprint. 

  4. Align Epics to the product owner - Most product owners that I've worked with don't have the time or technical skill to write stories and are usually expressing their requirements as Epics that are then broken down to Stories by business analysts and technical leads. When these product owner open the agile tool, they are more likely to review progress at the Epic level and only dive into stories when they need to review detailed requirements or better understand what part of an Epic has been completed. It's for this reason that the name, scope, and order of Epics are best aligned to the needs of the Product Owner. 

  5. Make sure stories are easily readable - Two different issues. First is if teams take the long route and make story titles too long making it difficult to skim read the backlog. The other issue (and more common) is if they are too short or filled with technical jargon that fails to express anything about what the story aims to get done. While the backlog is largely for the team, it is also used by the Product Owner, stakeholders and occasionally executives, so teams should make sure that at least the story title is easily skimmable and readable by the larger audience. 
  1. Tag stories that are technical debt - Tagging stories becomes really useful after teams have completed multiple releases and want to use metrics to guide process improvement. The first tagging worth introducing is on technical debt which can be used to serve multiple purposes. First, it creates accountability to the tech leadership to make sure that this debt is expressed in the backlog. Second, you can monitor and adjust the team's governance if the product owner fails to prioritize technical debt

  2. Test out of the box reporting early - All the agile tools that I've used have limited reporting capabilities but provide provisions for developers to enable more advanced reporting and analytics. The problem is programming the more advanced reports requires development time to build and support, so you only want to invest in this level of reporting when it's needed. That means, you'll want to rely on out of the box reporting wherever possible, but these reports typically have built in assumptions on what fields you are using and how you are using them. So it's best to test basic reports like sprint burndowns, release burndowns, defect reports, etc. as you configure the tool to make sure your implementation isn't limiting you from using them,

  3. Develop a filtering strategy and standard - As you get more advanced in agile practices, your sprints and backlogs will get filled with many issues beyond development stories. You might have non-developers taking on tasks, defects being worked on, estimating in progress and that will make it more difficult for individuals to work efficiently with the tool. The tools I've seen all have filtering mechanisms to enable personalizing views (show me only stories assigned to me) or other forms of filters (what tech debt is being prioritized? what is being estimated?), so it's best to enable fields and filters early in your roll out process so that they become standards across projects.

  4. Enable some experimentation - Even when you have multiple development teams, it's unlikely they will be practicing agile in a complete uniform way. It's equally likely that individuals on the team might discover new ways to leverage the tool that can lead or establish a standard for other projects and teams. So while standard implementations are necessary, don't box out some forms of experimentation.

  5. Involve the whole team - In my experience, there's usually a few developers that take ownership of the implementation and push the practice and tool configuration forward. Unfortunately, even when there is leadership by example, there are team members that are slower to adopt. So make sure that as you advance the practice and mature use of agile tools that you also take steps to bring the team forward together. Why is it important to record defects in the tool? Why should you add comments daily? How and when should you utilize specific reports? 

continue reading "10 Best Practices in Configuring your Agile Project Management Tools"