The Agile Data Organization - Balancing Responsibilities in Data Science Programs

If you've read this blog or have seen me speak at a conference, then you know I am a strong proponent of self-service BI programs. I've posted on principles of self-service BI programs, attributes of data driven organizations, and how to avoid data landfills among many other big data topics all aimed to get business teams successful competing and driving decisions with data.

But success isn't driven by technologies, data practices, or the value of the underlying data alone. It is people and organizational structure that truly drive success and yet this is where I see many organizations make classic missteps. The problem is in balancing responsibilities and making decisions on who does what steps in the data management practices, and who owns what decisions.

Three classic mistakes

Here are some of the missteps some leaders and organizations make when considering how to manage big data or self-service BI programs:

  • An overreached business team that tries to cut out IT from all or the majority of data management practices. In other words, data scientists on business teams trying to to turn "self service" to "complete control"

  • An overgoverning IT team that tries to provide technologies and identify structured business practices on every step from data gathering, to processing to delivery.

  • An overzealous PMO that tries to identify and label every part of the process and formally assign responsibility and decision making before the practice is in place and business value determined.

Hopefully you can visualize what's happening here. If you elect to be the overzealous PMO, you have a lot of up front work to define structure, process, roles, and responsibilities. If you choose not to predefine a structured practice with roles and responsibilities defined, then the organization will evolve its practice through experimentation and attempts to provide value. This is generally a good "agile" evolution, however, it, can lead to an imbalance depending on who has more organizational power and controls. Undisciplined business teams with little IT participation can lead to the first scenario and an overly controlling, "technology first" approach yields the second scenario.

What's the Solution To Getting A Balanced Business and IT Data Organization?


First and foremost, organizations need to recognize that this is not a unique problem to self service BI or data science programs. Agile product and software delivery teams are almost always cross-functional between Business and IT. The heart of agile is the product owner managing a backlog of features and enhancements, defining minimally viable solutions, working with IT on implementation scenarios, and prioritizing planning and development stories. Strong agile teams also have mechanisms to express and prioritize technical debt, larger business investments, and more significant infrastructure changes. 

The same practice can be applied to Agile Data Organizations, except that instead of prioritizing features, organizations look to prioritize big data questions. What questions provide value to stakeholders and customers that are worth answering? How do we attribute value and estimate feasibility on answering the question? How do we factor in other work such as loading in new data sets, data cleansing efforts, or improvements in data processing?

The next step is to get a team working together on discovery efforts. Once a multidisciplinary group understands priorities, there is a stronger likelihood that they will work together and disregard organizational boundaries and responsibilities.

Want to get started? See my related post on agile leadership practices to help data scientists.

But that's the start. There are some fundamental differences between software and data analytics that also contribute to the organizational discord. More to come!


continue reading "The Agile Data Organization - Balancing Responsibilities in Data Science Programs"

Five Takeaways from Mobile Enterprise Boston

Last week I attended M|Enterprise Boston, a conference that brought together technologists ahead of the curve in mobile application development, IT executives looking for best practices on mobile device management in large enterprises, and leaders looking to help their business gain a competitive edge by developing differentiating mobile capabilities.

My takeaways -

  • Use Hackathons to get developer adoption - Mahesh Bala of Snyder Electric scheduled a hackathon to get developers across the globe to try out his mobile development platform. It's a brilliant idea for two reasons. First, for developers that were already developing mobile apps in his organization, the hackathon provided a venue to learn, tinker, and hopefully by into a standard development tool and methodology for developing future applications. For more novice developers, it was an opportunity to learn a new skill and gain confidence to develop mobile technologies. Given how hard it is to get a decentralized group of developers to adopt a development standard and how important it is to grow an enterprise's mobile development talent pool, this approach is simply brilliant. In addition to the innovation developed at the hackathon, I am certain Mahesh got value feedback from the developers on where to make platform improvements. 

  • Use Genius bars to help users - Apple's genius bars are a huge success in getting its users everything from basic support to important training and problem solving. Why not use the same approach in the enterprise? Brian Katz @BMKatz talked about his enterprise's approach to setting up internal genius bars to help its users fix issues and learn how to better use their mobile devices. Smart to be present and make it convenient for users to find technologists rather than wait or hope that they dial into Support.

  • Day in the life of a user - There was a good amount of discussion on the importance of understanding user needs and work flow before designing applications. The best and most simple advice I heard - and apologies for not remembering the source - was to have members of the team walk in the shoes of their target users and experience a day in their life. Why? Because for mobile applications to be useful and used, they have to provide significant benefits at the right time and place and a good way to understand their needs is to experience it directly.

  • Agile development of mobile applications was debated politely. Many participants stressed the importance of identifying user persona, needs, workflows and to design the user experience while others were more vocal on agile principles. The two are not mutually exclusive and all agreed that mobile app development should target a minimal viable product but needs to be good enough so that users don't download, disappoint and drop.

  • Mobile analytics is the key to understanding user behaviors and tuning mobile applications and possibly more important than web analytics. As Adrian Bowles @AJBowles put it so well, the intersection of mobile and analytics is being "aware" so that the app is always on and collecting data and "everywhere" the user goes you have the ability to provide value and capture insights. The combination of mobile with analytics, assuming strong privacy considerations is a strategic differentiating tool. 

continue reading "Five Takeaways from Mobile Enterprise Boston"

The Future of Works Starts with Fixing Bad Meetings

How do you manage meetings so that they are productive and complete with documented decisions and prioritized follow up tasks?

This is a big, but an important topic. A lot of people's time and a corporation's spend is burned in meetings, yet most people can recount the bad meetings that were a waste of time versus others that had tangible outcomes. 

Why is it that executives with years of experience and advanced degrees struggle with the simple task of gathering the right number and mix of people, establishing an agenda, managing the meeting time, and insuring the proper documentation is disseminated?

I can hear some people saying that agenda-less meetings are also important. Blue sky meetings? Catch up sessions after a long break? Agile standup meetings that have a defined protocol? I agree that there are many meetings that may not require formal definition, but still require some structure. 

Is the Problem People or Technology?


Today, there is relatively low cost to set up a meeting. Jump on Microsoft Outlook, identify participants, find room on their schedule, book a meeting room and add a one line Subject. Most of the work is tied to answering who, when and where - very little on the what! Microsoft wanted to make it easy on business users to schedule meetings so the focus is on logistics and very little substance is required.

So what if we used technology and implemented some rules?

  • Every meeting requires an agenda - either a description or ideally a schedule of topics
  • Scheduling a meeting requires identifying two roles - A leader, for the person in charge of the meetings agenda and outcomes, and a Scribe, the person required to document decisions and follow up tasks.
  • Meeting costs calculated - Most meetings have too many people invited. I'd prefer implementing some form of governance, like meetings can't have more than eight people without an approval, but this may not be practical. Instead, what if the cost of the meeting was transparent to its leader? Even if the cost is calculated off of a simple flat hourly rate for all employees, publishing the cost will give the leader a sense of accountability.
  • Meetings require check in - when they arrive at a meeting. Better yet would be to install beacons in conference rooms to automatically record check ins. Dialing in or using a virtual meeting room? These tools could be configured to automatically log in the check ins.
  • Meeting outcomes are documented - and collected by the Scribe in a centralized tool that captures decisions and assigns follow up tasks. By definition, the Scribe is automatically scheduled time after the meeting to complete this documentation. On completion, participants are automatically emailed a link to the finalized meeting report that includes its agenda, participants, decisions, and follow-ups.

But It's People...

While this technology helps, it's peoples behaviors that also need to change. Some of these tools are expensive to implement (beacons) and can easily be circumvented. So this will require collective participation, collaboration, and a little bit of self policing to make a transformation successful.
continue reading "The Future of Works Starts with Fixing Bad Meetings"
Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.