Monday, March 23, 2015

An Agile Approach to Finding Value in Dark Data

It's been almost two years since I last blogged about the threats and opportunities around Dark Data, so when I was asked to join Joseph Bradley in Cisco's Future of IT podcast on Navigating Dark Data To Find Hidden Value in a Digital Era I couldn't resist.

To remind everyone, I provided the following definition of Dark Data in my post
Dark data is data and content that exists and is stored, but is not leveraged and analyzed for intelligence or used in forward looking decisions - Isaac Sacolick, see full definition

Since then, the subject of dark data has been covered by CIO.com (The Dangers of Dark Data), Forbes (Factories of the Future), and VentureBeat (Are you afraid of the dark data?). VentureBeat points to the cause of the problem, "
As storage has become cheaper, those who generate data have grown used to hanging onto it... When data is “dark,” it’s often because the organizations that own it lack the tools, infrastructure, or skills to effectively leverage it - John Joseph
Internal Dark Data, that is, dark data that is already captured and stored by the enterprise but not leveraged to drive insights or decision making represents a threat and a possible missed opportunity. The threat is if storing the data impacts the performance of a key business operation or contains sensitive information that should be better secured. The opportunity is to really figure out the value in retaining and processing this data.

Determining the Business Value of Stored, Dark Data


One of the themes we discussed during the podcast is developing the discipline on identifying the business value in dark data. To do this, use basic data visualization, analytics, and quality tools to identify the substance of the data and look to answer some basic questions:


Agile Data Discovery of Dark Data

  • How to catalog the data so that business users can learn about its existence? Can the data be broken down into basic entities, dimensions, metrics and volumes to provide more details to business users looking for data sources?

  • Identify 3-5 potential questions, insights, decisions, or activities that can be researched using this data should someone commission a data scientist to investigate.

  • Also identify "know issues" with the data source. This can be measures of data quality, information on how the data is sourced, and other feedback that might undermine any analysis of the data.

  • Have a Data Governance board "score" this data set based on its potential vs. known issues. Absent of  any easy way to quantify value, scoring by a voting committee can at least rank what data sets look attractive for further analysis.

  • Commission time-boxed studies (aka, agile sprints!) on data sets that have the highest scores. Review results and re-rank based on findings. (Note: See my post, Best Data Visualization Practices in Self Service BI Programs for some ideas on how to implement.)

  • Make sure that you have disciplined agile data scientists. Have them demo their findings to the Data Governance board and adjust the Score based on what was discovered.
As I said in the podcast, I suggest data scientists look at the value of data before investing too much time in discovery. Imagine that all the friction in the analysis because of the data set's size, speed, complexity, variety, or quality can be "solved" given sufficient skills, tools, and time - what do you hope to get out of this data analytics or mining exercise?

For additional insights,see my post 10 Attributes of Data Driven Organizations.

continue reading "An Agile Approach to Finding Value in Dark Data"

Tuesday, March 17, 2015

How the CIO Can Lead Digital Transformation

Is Digital Transformation an important business priority, or is the latest buzz word and attempt to get businesses to invest more in their technology programs?

In the '90s businesses were told to invest in their web sites and digital advertising. In the early part of the century they were told that web 2.0, user generated content, and social networking was going to create a new paradigm and that they needed a social strategy. Over the last couple of years, Accenture, Forrester, Altimeter and other analysts define cloud/SaaS, mobility, social and big data as the "nexus" of a "formal effort to renovate business vision" around a "digital customer experience". But is it a business transformation, or businesses adopting its strategy to leverage shifts in technology capabilities and customer expectations?

Digital Transformation or New Technology Capabilities?


I spoke to Gil Press about this and he recently published the 5 Things to do When You Lead a Digital Transformation Effort based on our conversation. Gil and I agree is that business models need to change for this to be a real transformation. Just like previous decades, certain businesses and industries are more likely to be disrupted or transformed through digital transformation while others will see tangible but not necessarily transformation benefits.

Leading the Business through Transformations


Here is a summary of my key recommendations:

  • Strategy - Look at the business strategy through the lens of technical capabilities and how that changes how you are operating and generating revenues

  • Execution - Agile planning and agile development allows everybody to see both the forest and the trees but focus on the trees

  • Iterative Experimentation - A lot of innovation comes from that mindset—encouraging experimentation

  • Find Aggressive IT Leaders -  Get them the tools to start, allow them to fail a bit and give them time and cushion to work out the new technologies and challenges they trying to master.

  • Target a Data Driven, Collaborative Culture - Collect meaningful data, convert it to metrics, look for trends, and prioritize improvements. Become a data driven organization.

You'll find a lot more detail in the article. Whether these technologies will truly transform the customer experience may be an unanswerable question until the effort and some investment is made. Will you lead, be led, or be passed by?



continue reading "How the CIO Can Lead Digital Transformation"

Monday, March 09, 2015

How To Write Meaningful Agile User Stories

Many teams struggle with defining "good" Agile Stories. Newly formed agile teams sometimes struggle with the basics, "What is a story?" and can be challenged understanding the difference between a story, group of stories, epics or tasks. A mature team can easily overwhelm a Story with implementation details and acceptance criteria to the point where the value of the story to the User can get lost in all the details.

I should point out that there is plenty of good reading on this topic; Mike Cohn's examples, several good tips from Roman Pichler, Alec Cowan's thesis on Your Best Agile User Story, and Bill Wake's classic INVEST principals.   There are also a good number of agile books either dedicated to story writing or cover it as part of the overall agile practice.

My list below is both strategic and tactical. The strategic part aims to get team participants, business stakeholders and others an easy to consume list of developments - a level of communication and engagement aimed at improving IT culture. The tactical part aims to get all team members - not just the developers but also QA, Ops, and other participants to have a shared understanding of what's being asked for by the product owner and important for the success of the program.

Principles of Good Agile Stories


  • Key stakeholders must achieve a shared understanding of the deliverable - Stakeholders here start with the Product Owner and the Technical Lead but should also extend out to members of the team when they review the story.

  • Stories should convey the opportunity, issue, need or value that it will deliver - It should convey the what, why, for whom and for what benefit? It should have less detail on the how.

  • The Story Title should be short and convey the deliverable without reading the details - Many agile practices require sharing a list of stories with a larger audience, so being able to skim through the titles and understand the intent is very important when working with stakeholders, facilitating demos, or efficiently grooming the backlog.

  • Good stories deliver an atomic increment in business value - This essentially separates a "story" from a "task"; a task is a technical step and completed in isolation, may not deliver value. A product owner should be one step closer to the goal (vision) by having the story completed. Why atomic? This is a discipline to keep stories small and more often than not, a story that delivers more than an atomic unit of value should be broken down to multiple stories.

  • Stories need to be completed in a Sprint - Which is another reason they need to be small.

  • Good stories have sufficient acceptance criteria. These criteria are like a short contract and should establish a shared understanding of the requirements with the product owner and define "done". They are often written as pass or fail criteria to insure there is little or no ambiguity. Good stories should also reference technical standards covering security, performance, naming conventions, quality and other nonfunctional requirements that define technical acceptance criteria.

  • The team should be able to estimate the story - If the criteria is clear, the team should be able to either provide an estimate for its delivery, or acknowledge that it requires some research and document one or more time-boxed spikes (usually these are separate research/development stories that enable the team to experiment with one or more technical solutions) to flush out unknowns.

 

Why Principles?


My principles deviates from some common practices and emphasize some key principles. I don't like stories that begin with "As a user, I would like to... " because it adds to the length of the story title making it more difficult for participants to skim in a list. I like the word "atomic" vs. independent, because it  orients the team toward small wins and simple products. I also think that stories should reinforce architectural standards and open a dialog with the product owner on value versus estimate or where research is required.

Above all else, remember that stories are a communications tool. Keep it simple.




continue reading "How To Write Meaningful Agile User Stories"

Monday, February 23, 2015

Ten Ways To Improve IT Culture with Agile, DevOps, Data, and Collaboration

Over the last decade I've had the privilege of working with several IT teams that transformed themselves from minimal credibility with the business to delivering award winning customer facing products while improving other IT business services. Different groups with different issues and opportunities, but what stands out with all of them is their willingness to change and improve their own culture

So coming off several posts on DevOps and how its practices combined with agile development can lead to an improved execution, I thought to share some incites on how to recognize and improve IT culture.

Signs that IT culture is Heading in the Right Direction

  1. Agile teams get things done first, worry about process mechanics later - When introducing agile practices - or even when agile has been used for some time and the team is looking to mature its practice - I find that strong teams will think agile, focus on execution first, and address mechanics of the process second. So for example, a new agile team should gets its backlog going first and commit, worry about story points and how to handle unfinished stories at the end of a sprint later. A mature agile organization with multiple teams prioritizing stories, figures out the communication mechanics between teams during the sprint, and formalizes communication practices by discussing issues at retrospectives. 

  2. Know how to use the business' products so that they can see where and how to make improvements. User interface, workflow, and access to insightful, actionable data is so important to successful customer facing application design and business system workflows that the technologists working on them have to step into their user's shoes and learn for themselves.

  3. Individuals are hungry to learn more and take the initiative to train themselves - Sure I can get individuals and a team formal training, but that's not where it starts. A strong IT culture prefers rolling up the sleeves and experimenting first, training once they know the basics. 

  4. It's not always the Business' fault - Agile teams might blame the product owner for over promising and everyone has something critical to say about the business strategy, but strong IT teams will think through how to improve their own practices before tossing blame or being critical of other business functions.

  5. Speak openly about where they suck and need to improve is important. I want to hear about technical debt from software architects. Ops team need to look at metrics and decide where improvements can have business impact. QA needs to own up when their testing is inadequate. Most importantly, teams need need to speak up when they recognize a problem - and a problem well stated is half solved.

  6. Share information on how things work, document process, and educate colleagues on how to fix things. IT teams that horde information, over-complicate things so that business users don't understand how things work, or make it impossible for their colleagues to enhance their technical implementations are impeding organization growth and scalability.   

  7. Want to get involved understanding business priorities and challenges. They ask the product owner questions on the priorities or want to understand how their efforts are contributing to growth or efficiencies. They'll seek out multiple solutions to a problem and debate which ones provide optimal solutions. They'll listen to marching orders, but seek out to participate in the debate on what and how the business should move an agenda forward. They are strategic agile thinkers and learn how to innovate.

  8. Leverage data and ask questions - To become smarter about their own operations, they will collect meaningful data, convert them to metrics, look for trends, and prioritize improvements. They will learn to ask good questions about data, and take other steps to help become a data driven organization.

  9. There is an interest in spending time together outside of the office and having fun - My last team threw summer family picnics, and assembled everyone for pot luck Diwali celebrations. Good teams want to spend time together, celebrate wins, appreciate individual interests, and be human. 

  10. Are responsive when there are operational issues - It's one thing to have all the systems monitored, ITIL practices to handle incidents, playbooks to recover from an issue, and strong technical skills to research root causes - all things strong Ops teams work toward - but the best ones also develop a good bedside manner, are responsive to even the most difficult users, find ways to communicate using language everyone understands, and make sure business teams receive regular updates when there are problems.

And here is one bonus one - probably the most important

  1. Great IT teams refuse to fail, are willing to take on challenges and find ways to make their initiatives succeed.They are relentless to hit deadlines. They seek to keep things simple. They promote enthusiasm and heal downers and doubters. 

continue reading "Ten Ways To Improve IT Culture with Agile, DevOps, Data, and Collaboration"

Wednesday, February 18, 2015

Seize the Day! The Ops Role in DevOps Transformation

Reviewing some of my latest DevOps posts. I've covered why DevOps is important, asked the question Who Owns DevOps and answered that the CIO needs to own transformation initiatives. In my last post, I stated that agile development teams should stick to owning the practices tied to Development like automating testing and standardizing deployments so that they stay aligned and focused on initiatives that improve customer experiences, automate workflow or generate revenue

So, what is the role of the Ops team in a DevOps transformation? Can the team responsible for keeping the lights on, resolving incidents under expected SLAs, handling requests to deploy application upgrades, insuring that business systems are secure, keeping up with the latest patches and upgrades transform their practice with DevOps?

DevOps Practices is really About Agile Ops


If the CIO owns the transformation and Dev is largely providing a supporting role, then the opportunity to transform is really with Ops. Here's my extended rationale:

  • The real benefit in cloud environments is with enterprises that manage thousands of server instances and petabytes of data and where standardization and automation provide significant cost advantages. New configuration tools like Docker, Puppet, and Chef are designed to automate configuration management to these extremes - but it is Ops that should learn the technology and take on the responsibility of configuring them. Same responsibility (configuring systems) new tools.

  • Agile development teams have already aligned their effort to business driven priorities, but their frustration is when Ops or the infrastructure can't support frequent changes. Perhaps Dev needs to spin up new environments to test an upgrade or evaluate a new platform and it takes too long to configure? Maybe releases need to be scheduled more frequently but the deployment steps are too complicated? These are Operational accountabilities that might require contributions from the Dev team. Ops should collaborate with Dev to define application, configuration, and other changes that will drive the capability to release more frequently. 

  • The increase in cloud instances and applications - along with higher expected service levels from customers and stakeholders require an updated approach to monitoring applications and collecting performance data. Applications need many more monitors, real time alerts, and longer time frame performance trending. Ops teams need to invest in their skills to respond to this greater need.

  • Security is only going to get more business critical and more difficult to perform. Because Ops is in the front lines protecting security, they are in a better position to drive infrastructure and configuration standards that help simplify the disparity of assets that need secure configurations and support.

  • Server loads are increasingly more dynamic especially when many applications must handle variable loads driven by global, big data, or mobility computing needs. Ops are already versed in handling load balancers, application clusters, SANs, SDNs and other tools to dynamically scale system resources. The additional automation tools might require more "coding" but should not be outside of Ops ability to learn.
Ops should seize the day and take responsibility for these improvements and transformations. When agile development teams elect to tackle these challenges, they are doing the overall business a disservice by focusing on operational needs rather then business improvement drivers.

What about DevOps culture? Should Dev and Ops run as one team? Next post!



continue reading "Seize the Day! The Ops Role in DevOps Transformation"

Monday, February 09, 2015

Why Agile Development Should Not Own DevOps

Thanks to Ramon Monteiro @ivisualize for developing this cool visual depicting my last post on The Key to aligning Agile Dev and Stable Ops to a Successful DevOps Transformation. While agile development teams continue to iterate and improve applications for the Business, and Ops insures that systems are stable and reliable, the CIO leads the entire IT organization through a DevOps transformation.


Warning! Let Ops own Operations


Somewhere in the emergence of DevOps tools and practices some agile teams have taken the initiative and gone beyond their core responsibilities into system and operational domains. Some argue that because tools like Docker, Chef and Puppet enable software driven configuration management and scripted system deployments that it now falls under Development responsibilities to program virtual environments and automate their scalability.

Don't Cross The Streams! Developers Stay Left!


Review my last post. When I lead a group of developers, I target them to spend at least 70% of their time on development efforts that directly improve business capabilities. That means they only get 30% of their time to operational and support tasks like responding to incidents, addressing application lifecycle issues, resolving technical debt, and improving development processes. All of these are critically important, but keeping up with these responsibilities is a tall order and difficult to fulfill within their 30%.

Dev simply doesn't have the time to take on additional operational responsibilities. They should not be involved configuring servers or automating their configurations. If they are going to participate in a DevOps transformation, they should support their Ops teams by focusing on the Dev practices of DevOps such as standardizing their application builds, automating testing, or strengthening their version control practices.

Why Agile Development Teams Cross the Line?

Agile development teams by definition should be self organizing but if there is a need to take on DevOps practices they may elect to put this work on their own backlog. A product owner that senses infrastructure or operational gaps may support them. If there is a strong cultural divide with Ops, if there is weak governance on procuring infrastructure (including cloud), or if there aren't practices to insure development priorities are applied to appropriate technical functions then agile teams may cross the line and take on Ops' practices.

This isn't the answer. I doubt agile teams would like their product owners to start designing databases or developing technical standards (though some try to) because they lost confidence in their development teams. Development teams need to have a similar respect and collaboration with their Ops teams regarding operational responsibilities.

If Ops teams aren't getting it and DevOps is a strategic priority for the CIO, then he/she needs to work that out with the Ops team's management. If the CIO accepts Dev stepping in, then it might create longer term animosities or produce conflicts with fulfilling business priorities.

How can the CIO Help? 


A CIO should recognize when one team needs support and another team is overrunning them. If an Ops team is struggling with the new operational practices and tools of DevOps, the CIO needs to step in and pace the program accordingly Some options:
  • Define roles and responsibilities so Dev and Ops understand who owns what DevOps practices and where collaboration is required. 
  • Bring in a coach that adapts to the CIO's and organization's governance and culture. 
  • Recognize skill gaps and address by bringing in experts, investing in training, and providing sufficient time for practicing new skills.
  • Define reasonable scopes and goals especially on transformation initiatives.
 


continue reading "Why Agile Development Should Not Own DevOps"

Tuesday, February 03, 2015

The Key to aligning Agile Dev and Stable Ops to a Successful DevOps Transformation

.
So who does own DevOps? I left readers with this cliffhanger after my last post and my intro post on The What, Why and How of DevOps. If an organization is embarking on a DevOps transformation, how should it be led so that Dev and Ops teams are likely to collaborate more and battle less in adapting and maturing new practices?

To answer this question, I would suggest we get back to basics and review the role of Dev and Ops in an IT organization.

Dev Must Align with Business Priorities


The Development team should operate as the technology extension of the business. This means that they must be looking to provide expertise around enterprise applications and specifically on how business users can be more productive, drive data driven decisions, connect with customers, or make supply chains more efficient. It means that they have to be spending their time building or enhancing applications. When looking at how the Dev team spends its time, ideally they aught to be spending 70-80% of their time developing new capabilities and ideally only 20-30% on "support".

Therein lies a key question - what is support? I'm using Support as a catch phrase for time spent on any other non-administrative tasks that is not Development. It could be chasing an operational incident or diagnosing a defect. It could be upgrading versions of anything from an enterprise application to a javascript library used in an application.

And... it can also be anything technical to make the Development team more efficient. It can be investing time in configuring version control, automating builds, or scripting deployments. It can be time spent researching technology tools. All of this time, while very critical to an efficiently running Development program is time balanced against direct efforts to improve the business.

Many Dev teams have adopted agile development practices to better align with the business and to focus their development efforts. The successful ones will deploy frequently and push their Ops teams to support more frequent changes. But while Dev teams optimize for speed and agility, then may compromise stability and quality. When this happens, it is the Ops team that often feels the pain points of fixing what Dev released.

Operations Align with Stability and Reliability


While Dev is optimizing for speed and may compromise reliability, Operations has the opposite charter and look to insure the performance and reliability of the environment as their top priority. Their practices such as incident management and change management align with this charter and aim to protect the business from disruption. Disruption can be outages that affect customers and business operations, but also mean incidents that hamper organization productivity.


The byproduct of protecting the organization is often rigidity. Examples include infrequent time windows for change management or lengthy lead times to deploy new infrastructure. Ops teams may also suffer by only learning systems view of monitoring a system - the system is up vs. the application is performing as expected.
 

DevOps Practices Align Development and Operations


DevOps practices are designed to make Development more reliable and Operations more agile and nimble - effectively helping each organization with their weaknesses. For Development, practices such as automating test cases, scripting application deployments, and standardizing application builds all aim to improve the quality and reliability of hand-offs from Development into Operations. For Operations, standardizing system configurations, automating server changes, and scripting cloud operations are all tools to help automate Ops and enable them to be more agile with infrastructure. Therein lies the transformation, and more specifically a better balance between agility and stability.

So Who Leads DevOps?


The transformational CIO does. Transformation requires a senior leader to sponsor the investment, prioritize the effort, and market the wins. Transformational efforts that cover multiple practice areas need leadership to help prioritize and set the scope of the effort.

But regarding Dev and Ops collaborating through a transformation - the CIO needs to step in and redefine objectives, roles, and responsibilities. In what areas does Dev need to be more stable? To what business benefit and to what extent does Ops need to become more agile? When instituting a configuration management tool, what is Ops' primary objectives and where must Dev contribute?

The CIO needs to lead these discussions, set priorities and secure the collaboration required to make this transformation successful.

continue reading "The Key to aligning Agile Dev and Stable Ops to a Successful DevOps Transformation"

Share