Wednesday, April 22, 2015

Don't Let Your SaaS Solutions Become Tomorrow's Data Silos in the Cloud


Can your SaaS platforms support data and workflow integration or are they data silos in the cloud?


I'm a big proponent of SaaS solutions especially when they offer simple user interfaces, configurable workflows and advanced analytics that enable the targeted organizations to be more productive and data driven. I prefer partnering with experienced SaaS providers that can deliver on their value, offer advanced functionality and have secure, reliable infrastructures. Even better are PaaS platforms that enable application development.

Enterprises are maturing their use of strategic SaaS/PaaS platforms and also experimenting with innovative SaaS solutions that deliver new capabilities. I went searching for research on how many SaaS platforms enterprises were utilizing and found that companies, on average are using between five and nine SaaS platforms and the number is expected to grow to thirty over the next three years.

How will the CIO integrate data and workflow across multiple SaaS platforms?


But while top SaaS platforms offer advanced functionality, scalable infrastructure, speed to market on new capabilities, and often lower costs, using many platforms creates some new challenges.

Every SaaS platform captures content and data, enables workflow and collaboration around its core capabilities, and provides some out of the box reporting capabilities. Ideally, these features should be "good enough" to unlock its core value, but a key question is whether the platform is "sufficiently open" to enable integration once usage hits critical mass and the platform becomes more business critical.

"We have API's" - But Are APIs Sufficient?


When you investigate a SaaS solution's integration capabilities, the canned answer you'll get from a sales rep or that you will likely see on the website is about APIs, SDKs, App Stores and Developer Programs. The more marketing around these capabilities, the more third party apps available, and the more developers there are in the program the more likely these integration tools and the skills required to leverage them can be used to achieve a desired enhancement or integration. If these integration capabilities are not prominently featured on the vendor's website and if there is little evidence of how, where, and how much they are used, then you should consider investing due diligence effort and ideally prototyping to determine whether the platform "scales" and both its data and capabilities can be easily integrated.

But APIs, SDKs, etc. are all tools for developers and require engineering efforts to leverage. In addition APIs are proprietary so there is a learning curve to every one that is needed to fulfill integration needs. What if I am trying to implement a more simplified "out of the box" data integration? Specifically -

SaaS Integration A Key Concern and Opportunity


The better SaaS solutions will have mature APIs that have had significant customer usage. The better ones will enable direct integration with other platforms and simple tools for business users to connect workflows and data. The ones to watch are thinking three steps ahead and building on-ramps for your organization's future digital transformation priorities, IOT strategies and other integration needs

But the real question - are you evaluating platforms on integration capabilities? Are you investing in integration where it is necessary or provides value? Are you training developers on the capabilities of the platforms and fostering a culture of experimentation?

Or will your SaaS platforms be big data silos in the cloud?

continue reading "Don't Let Your SaaS Solutions Become Tomorrow's Data Silos in the Cloud"

Tuesday, April 14, 2015

5 Principles on What Makes a Great Agile Development Team

The CIO must learn and drive the business, set the strategic direction for IT and proves that he or she can get teams executing to the strategy. I've posted many times on how agile practices are key to a CIO's success because it creates transparency, dives culture change, and is a key element to innovation.



IT is All About the Team


So yes, strategy is important. A process to manage execution is very important. But in reality it's all about the team. It's the team that must learn the strategy, execute, improve practices, and deliver great results on time. Over the last several years at BusinessWeek, at McGraw Hill Construction, and now at Greenwich Associates I've had the benefit of working with great teams and individuals.

What Makes A Great IT Team


Here's a short list of what makes a well executing IT team 'great' -

  • Disciplined on Solving The Right Problems  - Ever been in a meeting that seems to drift from one topic to another without fundamentally solving anything? Many teams have this problem, but the best ones develop the discipline of prioritizing "Problems to be Solved", focus their meetings on the problems assigned to the agenda, and use "parking lots" to capture tangential questions that need addressing. Strong teams know that fewer, more productive meetings are a key to getting more done.

  • Courageous to Ask Challenging Questions - The only way for teams to develop a shared understanding is for them to ask questions. More importantly, because product development needs to be data driven, I encourage development teams to ask questions even to the point of challenging their product owners. This dialogue is critical in order to get a firm understanding of what and how to get things done and to help drive toward a simple product definition.  

  • It's Not Just Getting IT Done, But How You Do IT - I tell teams that is equally important to me how they get things done - not just whether they got them done. Are Agile stories well documented with acceptance criteria then estimated and sized before the Sprint start? Are database and software architecture considerations factored so that new development is targeted toward a reference architecture? Are standards for QA and performance, reliability, security, and data capture factored in?  

  • End to End Agile Culture - Great teams work with ambiguity and know how to think agile. They learn how to fail fast. They partner with IT Operations on a DevOps practice. They are disciplined with retrospectives and optimize agile for increasing velocity, improving quality and developing other practice improvements. 

  • Lead Data Driven Mindset - Strong teams are data driven. They learn how to capture data and develop metrics to drive their priorities and decision making. They lead by example with the CIOs self-service BI programs. 

A Special Thanks


So these are the teams that I have to thank for success and some recent recognition on Forbes, (5 Things to Do When Leading a Digital Transformation) and Sync Magazine (Portrait of the New CIO). Thank you!

continue reading "5 Principles on What Makes a Great Agile Development Team"

Monday, March 30, 2015

New Agile Teams - Common Questions, Simple Answers

Many readers of Social, Agile, and Transformation know that I've recently started a new position as Global CIO of Greenwich Associates. When I came in, I committed to the team that we would rapidly adopt Agile Development and Agile Planning practices in order for us to fulfill our goals. Today, less than one hundred days into this position, we have Scrum running in three programs and Kanban running in a fourth - a great start.

Agile purists would recognize that we are still in the early days of adopting the process, but we are showing measurable results on our goals as we build up the practice. How? By keeping things simple and adapting practices as needed.

Answers to Common Agile Questions


Below are some of the questions I have received from new agile teams across several organizations where I have started the practice. The answers I provide below are tailored to new teams working on the process.
  1. How can we write "good" Stories? - Focus on writing Titles that convey the deliverable and gaining a shared understanding of the requirements rather than the particulars of how the story is written. See my recent post, How to Write Meaningful Agile User Stories for more suggestions.

  2. What should we do with Stories at the end of a sprint if they aren't done? In early sprints, I prefer teams over commit because it leads to a better understanding of what it means to commit, how to question the intent of stories, and how to begin measuring velocity. If the story isn't done, rewrite the story to better represent what was Done and write a new story (or stories) on what needs additional work.

  3. How should we show dependencies between stories? - Avoid doing this in the early days. It's a feature sometimes asked by people who are used to working in MS Project and still believe they can project all the tasks and dependencies on a project. Instead, I reinforce agile principles and ask teams to project their backlog and focus on having user stories fully defined and committed for the next sprint.

  4. How can we demo a story that does not have a user interface? Purists might argue that a story that doesn't have a customer facing deliverable is a poorly written story, but for new teams and ones working on new technology platforms, this may be difficult. Ask the team to demo a test case, a data diagram, or something that illustrates the quality of the deliverable.

  5. Should we capture requirements gathering as a story? There's nothing fundamentally wrong capturing these as tasks especially if multiple stakeholders are needed to work on the requirements.

  6. How do we represent non-technical tasks? Agile is not just for technology work and the practice produces better results if all aspects of the Product are represented as User Stories or tasks. So yes, capture the data work, training, marketing, and other business activities as a Task or other issue type in your backlog and sprints.

  7. When can we see a schedule? - Agile teams need to run first, worry about plans and schedules second. Get the backlog going and commitment running first and focus teams to prioritize on value and risk. Once teams get through sprints and resolve most of the open questions, their ability and willingness to project the full backlog emerges. It's only when there is a credible backlog and understanding of velocity that more realistic scheduling becomes possible.

Further Reading as Teams Advance


Here are some of my more popular posts on advanced agile development practices. Many teams are concerned about consistency when advancing from multiple agile teams to an agile organization. I have several posts on estimation and this one on feature estimation is a good start. Many teams are also interested on increasing their velocity or better integrating agile with software architecture practices. Here's one if you are working with offshore or distributed teams and one if you are still working on getting the CIO or an executive sponsor for the agile program.

It takes time. One sprint at a time!

continue reading "New Agile Teams - Common Questions, Simple Answers "

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"

Share