Monday, June 22, 2015

The Most Important and Often Underinvested IT Function

If you're practicing agile development without QA team members, a reasonably defined testing process, and sufficient criteria to help define "done", then at some point your development process will go off the cliff of complexity.

That's right. No QA, off the cliff you go without a parachute.

The size of your development team, the number of technologies used in the development stack, and the business criticality of the applications are all quality criticality indicators. They shape how much runway IT has before quality factors drive material business risk that can easily overwhelm the IT development and operations teams.

Even if you're a solo citizen developer on a low code platform, at some point you're going to make application changes where having defined test plans help avoid issues that might impact users, customers, data quality, security or performance. In larger scale applications, performance testing is not something you can do on demand because the first load always fails and valid testing practices need to be implemented as part of the agile development process.

Why a QA Practice Is Critical to Long Term Success

Let's look at some basic concepts that point to why QA is so critical to businesses that rely on technology
  • More functionality, more testing - As applications are developed with more features and capabilities more functions need testing. Every agile sprint increases the testing landscape, and if the discipline to define test cases and establish regression tests isn't developed in parallel, the backlog to develop them becomes too hard and long to execute on afterward. If a development team is adding functions and then breaking others, it's likely because there isn't regression testing in place to catch these issues.

  • Applications are more complex involving multi-tier architectures, multiple databases, transactions spanning multiple APIs, and computing performed on multi-zone cloud environments. If you aren't building unit performance tests along the way then identifying a bottleneck can be a lengthy, painful process when it emerges.

  • Data and Analytics Testing - The application is working, but the data is wrong. Many applications today are data driven enabling their users - internal or external to make better data driven decisions. Application testing isn't sufficient because if the data is wrong, the entire value to the end user is compromised. But testing data, validating calculations, understanding boundary conditions, and insuring aggregations or statistic calculations are valid is really really hard without a defined test strategy.

  • Security Testing - A failed application security test may be costly to fix. Worse is a security failure in production that could have been avoided with security practices entrenched into the development practice. If you're not testing for security issues, then it's unlikely the development team is applying basic security design principles into developed applications.

  • Multiple devices, browsers - Finally, today's user experiences span phones, tablets, laptops, IoT devices with different browsers and plugins. Insuring that user interfaces are functioning and that the user experience is optimized across all these modalities has never been easy, however, customers have minimal patience for mediocre or clumsy experiences.


 Why Many Organizations Underinvest in QA?

The workflow may be broken. The data may be wrong. The user interface may look broken on an Android phone. The performance may be degrading over time. There may be a security hole just waiting for someone to exploit it. There is likely loss of revenue if there is an outage.

With so many things that can go wrong, why do many enterprises and the CIOs that lead them underinvest in QA?

Next post.

continue reading "The Most Important and Often Underinvested IT Function"

Monday, June 15, 2015

5 Key Practices - What IT Takes to be a Citizen Developer on Low Code Platforms?

Does the IT department and the applications development team have to own and lead all application development efforts?

Over my last couple of posts, I've been exploring how Citizen Developers - developers using light weight, often low code development platforms can help their business functions automate tasks, analyze data, develop knowledge repositories, and connect data across applications. As a CIO, I've developed citizen development programs and believe it may be the next big thing in application development, but it takes some discipline and defined practices to avoid the potential perils of citizen developed applications.

So in this post, I'll share some practices that will make these programs successful. Keep in mind that what you elect to implement from these practices will likely depend on the goals, strategy of the program and technical capabilities of the platforms selected. So for example, using IFTTT SaaS platforms like Zapier, IFTTT, or itDuzzit to connect SaaS data platforms may not need a lot of rigor, but self-service BI programs need lifecycle practices and IT provided data management services. It also helps to understand technical bounds, so low code platforms like QuickBase, Tableau, QlikSense, may be in scope for Citizen Development while others offering more technical capabilities like still require IT ownership or participation.   



What Practices Are Needed To Enable Citizen Developers?

There are several ingredients needed for citizen development to flourish.
  • CIO sponsorship of these programs is critical, otherwise IT will view the platform and applications developed by citizen developers as rogue IT. There is also a greater risk of citizen developed data silos or other unsupportable applications. CIOs that are not on board may communicate that these programs are contributing to enterprise data landfills or creating new data governance challenges. The last thing organizations need is a divide between IT and organizations that want more technology and are willing to roll up their sleeves to get it. Note, I should also point out that organizations selling low-code platforms should invest more effort selling and partnering with the CIO!

  • Formally define and communicate a strategy, list of example opportunities, and target platforms so that the organization can align on a selected approach and priorities. What you don't want is every department pursuing different platforms, or that the program is only successful with a handful of early adopting departments, or that citizen developers create applications that add more complexity than value.  

  • Establish the development practices and lifecycle for applications developed in these programs. Is there a review committee to determine priorities and appropriateness of platform? How are versions maintained? What naming conventions and documentation is minimally required? What UX/UI standards will be leveraged in these programs? How are applications tested? What security is required and reviewed? How are these applications monitored and how are end users support provided when required? When and how does the organization recognize that they've outgrown an application and a more scalable solution required? Who and how is it decided when venturing into coding practices, data integration, or API usage permissible?

  • Who are the acknowledged Citizen Developers? What skills are required to be part of the programs? How do you get their managers engaged and supporting the program? What training, mentorship, and rewards is provided to successful developers? How are best practice on developing applications shared with other developers?

  • How are you marketing, promoting, and providing access to successfully developed applications? Where is the directory to find these applications? How are access roles and other permissions defined so there is consistency? Who signs off on new user access? Who is solicited on priorities for enhancements? Who takes responsibility for rolling out and communicating changes to end users? 

This doesn't need to be overwhelming or hard and it doesn't need to be defined all up front. It also doesn't require all the rigor required of a software development lifecycle. This is just a sample of considerations and what to think about as a citizen development program is kicked off or  matured.

continue reading "5 Key Practices - What IT Takes to be a Citizen Developer on Low Code Platforms?"

Monday, June 08, 2015

The Perils of Citizen Developers

Mile wide spread sheets. String parsers that break when unrecognized characters are passed to it. Rapid fire queries that kill database performance. Forms that permit SQL injection. Hundreds or thousands of undocumented disparate applications that don't share data or design patterns. User experiences that have no consistency.

Is that what goes through your mind when you hear the words Citizen Developers?

This is some of the feedback I received after my last post, 4 Reasons Why Citizen Developers May Be The Next Big Thing in Application Development. In general, many developers scoff at the idea of giving "corp cube dwellers" this capability that lead to "desktop crapware". Citizen Development will "continue klunking along". My favorite comment, "If I had a penny for every time I have read development with no coding required." See the comments to my last post on Reddit.

Should Developers Scoff at Apps Developed by Business Users?

Software development and engineering is a craft, a skill, and a discipline. It's not mastered in a training course, a degree, or by being a programmer on a simple application. To develop robust, scalable, secure applications that can be extended and maintained often takes a team of multi-disciplined professionals working collaboratively leveraging various tools, aligning to architectural principals and design patterns in creating "software magic".

These same developers are often called in to rescue bad applications, or to investigate a systems issue caused by a poorly defined application, or blamed for a process failure because a hack of an app developed by a rogue developer isn't stable.

But these same developers also know there is too much work for them in the enterprise. They scoff at the idea of hiring mediocre developers to handle the demand or when business users work around their need for apps or reports. Many will shake their heads when looking at the work of spreadsheet jockeys or the legacy of data silos.

And the reality is, these developers would prefer building new, innovative applications where their work can have business impact. They want to work on the latest technologies. They are needed to help solve Big Data challenges, to help migrate more applications to the cloud, or to build customer facing mobile applications.

Citizen Developer Development Practices

I like the term Citizen developer. Not everyone is a citizen. Citizens are governed and have accepted values and practices. They are given a set of tools to work with and instructions on how to use them. I may be qualified to go to home depot and get the tools, materials and guidance to install a new light fixture that I need to do safely and properly. On the other hand, I'm not permitted to go upgrade the circuit leading to my home without a licensed electrician and the proper work permits.

So my next post will provide some governance, practices and specifics on What IT takes to be a Citizen Developer.

continue reading "The Perils of Citizen Developers"

Monday, June 01, 2015

4 Reasons Why Citizen Developers May Be The Next Big Thing in Application Development

I must be behind the times because last week was the first time I heard the term "Citizen Developer", a term Gartner defines as a user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT. They are referring to a business user and not a software developer in IT, and are careful to distinguish this from Rogue-IT which occurs when users select technologies not sanctioned by the IT department.

I have been a strong proponent of citizen development, though I've been using other terms for it on this blog. Self Service BI is a form of citizen development and a strong practice is a key ingredient to becoming a data driven organization. I also wrote The Best Line of Code is the One That You Didn't Have to Write! referring to PaaS platforms that enable application development with no or little coding required. I heard the term at last week's conference for Intuit QuickBase, one of the best platforms for citizen development of database driven web and mobile applications.

Why Citizen Development?

Gartner predicted that Citizen Developed applications would be 25% of new applications developed by 2014. I suspect the percentage today is lower than predicted, so here are a few reasons why this trend may take off in the next few years -

  • Understaffed IT Departments with greater business demand fro technology services - I've never seen an IT department with adequate resources and funding to tackle all the demands of the enterprise or organization. We spend significant effort to prioritize, identify business value, formulate risk scores, and calculate ROI to insure we tackle the most critical opportunities knowing that we can't manage every need and request equally and simultaneously. So one reason for citizen development is to handle technology needs to automate workflow, develop knowledge repositories, construct reporting dashboards, or process data in domains that are difficult for IT to service. Very often these are operational groups, finance, and marketing who have significant technology opportunities but are too often ranked lower in business priority.

  • DIY by SME's vs. IT's ability to capture requirements and execute solutions - It's also no secret that IT often fails to understand and translate business requirements adequately. When deep subject matter expertise is required to facilitate a relatively easy to implement technology solution, it can be a lot more efficient for a citizen developer working in the organization to develop a solution. Examples include data driven dashboards, departmental specific task management, lightweight CRM, or no-code content management systems (CMS).

  • No/Low code solutions should be easier and cheaper to maintain -The reality is that custom developed applications can be expensive and many organizations underfund their ongoing support. Typically, the application development team is asked to go on and build new applications, leaving limited applied resources to enhance or upgrade older applications. In addition, the rate of adding new applications is often faster than the rate legacy applications are retired. Citizen developed applications are largely low or zero code configurations and often deployed on SaaS or PaaS platforms. These applications should require less maintenance and are more likely to be enhanced if they are mission critical to the citizen developer's organization.

  • Emergence of tech savvy business users and functions - Finally, I believe there are technically capable individuals entering organizations in non-IT functions that are interested in taking on more technical responsibilities. They include data scientists working in analytical functions, data stewards working in operational functions, sales operations managers, or digital marketers. Given the right platforms, practices and governance these tech savvy users can become citizen developers.

So What's The Catch?

Needless to say that citizen development can easily become a next generation IT nightmare. A good quote from Citizen Developers Will Ruin Software

Citizen developers are only concerned with their immediate environment, looking at the problem that they are trying to solve so they can do their job, rather than seeing it in the context of the wider IT ecosystem.

I'm not sure I believe this has to be the case. Like all other technologies, it requires IT leadership to provide governance, practices, and guidance for technologies used by citizen developers. More in my next post!
continue reading "4 Reasons Why Citizen Developers May Be The Next Big Thing in Application Development"

Tuesday, May 19, 2015

Transforming Technology Organizations By Investing in Culture and Practices

Should IT only be a services organization to the Business? Should it only provide a services catalog around incidents and requests and a PMO to oversee projects when required? Will perfecting service levels and project execution be good enough for the Business to compete when innovation and data driven practices are so critical for competitiveness? Will IT be able to consider optimal solutions when they require a mix of Cloud, SaaS, and on premises components and significantly more data integration and application development across them?

That is the question facing CEOs, CIOs and IT leadership and many have come to realize that keeping the lights on and just getting things done in IT is not good enough. The new IT charter includes investing in Digital Transformation, enabling a Data Driven Organization, and maturing IT innovation to fuel business growth and efficiency.

IT Culture and Practices

I've been posting on IT culture to raise awareness how important it is when a business is trying to transform and innovate. My post, 10 ways to improve IT Culture with Agile, DevOps, Data, and Collaboration speaks to the good signs and ways to improve IT culture by investing in specific practices like Agile and DevOps. I went a little deeper with 5 Principles on What Makes a Great Agile Team and provided more specifics on what makes an agile development team succeed over long periods and contribute to IT culture. I then went to the dark side pointing out 20 bad behaviors of agile product owners and 33 Bad Behaviors of Agile Developers and IT Operations to highlight a list of behaviors that have negative contributions to IT culture. 

My message? If you want to improve IT culture, you have to target positive practices but also correct for negative behaviors.

Course Correcting Negative Behaviors

Let's look at some negative behaviors from my last post and consider options and solutions. What practices should IT Leadership focus on to improve IT culture and address bad behaviors? Here are three:

  • Drive Collaboration and Communication Behaviors to insure teams are working well with their business colleagues on opportunities, solutions, and innovation. To irradiate the dividing line between "requirements" and "implementation", the number of people in the IT team that need to be able to communicate and collaborate with stakeholders is significantly larger than in decades past. Improving communication is an easy starting point to get developers, system administrators, engineers, business analysts to be better prepared to collaborate. Here are some places to start: 

    • Mentally says no, or actually says no to an idea or request without listening to the business need and priority
    • Communicates in technical jargon or overly complicates the message back to a business user when responding to a question
    • Creates blocks and waits for requirements without engaging the stakeholder or proactively proposing opportunities, problems that need to be addressed, and solutions
    • Fails to regularly communicate status when resolving a critical issue

  • Evangelize actions that drive IT Efficiency - It isn't going to be easy to justify investments to fix manual work in IT or to dedicate application development releases to fix bad software. Both of these issues need to be avoided before they are created and fixed incrementally over time. It's why addressing behaviors like 

    • Fails to automate tasks and leaves significant manual steps in a technical solution or 
    • Creates technical debt but does not itemize it in the backlog to be fixed or 
    • Doesn't provide documentation, training, or other knowledge transfer to ensure colleagues can support the technologies he or she developed

    are critical because without making them, it is likely that any new technologies instrumented today will have "legacy" issues in the future.

  • Insure IT decisions are data and quality driven - IT is the hub of so much operational data, yet they often leave out the discipline required to review this data, develop metrics, and leverage in their decisions on priorities, problems, and solutions. If IT isn't using its own data, then how can it be a part of a data driven organization? In addition, if IT isn't paying attention to quality or security, then how can it deliver reliable and safe solutions? These behaviors underscore issues that need need to be course corrected: 

    • Chases rabbits when trying to diagnose performance issues without reviewing logs and metrics to guide efforts to areas of higher importance
    • Over engineers solutions and inflates estimates
    • Treats quality assurance, testing and security as an afterthought and doesn't bake these paradigms into designs
    • Doesn't implement unit tests, performance evaluations, or other test driven practices to ensure that code is reliable and functioning properly

Are you ready to lead a cultural transformation?

continue reading "Transforming Technology Organizations By Investing in Culture and Practices"

Monday, May 11, 2015

33 Bad Behaviors of Agile Developers and IT Operations

I recently published 20 Bad Behaviors of Agile Product Owners and decided not to leave this subject one sided. In trying to improve the organizational culture and more specifically, the culture in IT, the CIO and IT leadership must consider, review, and improve on its own behaviors.

So this week I'm itemizing some of the bad behaviors in IT. Like my previous most, I haven't seen these behaviors in any one organization or person - it's a collection that affects individual and teams from time to time some worse than others.


  1. Mentally says no, or actually says no to an idea or request without listening to the business need and priority
  2. Doesn't accept responsibility when there is a screw up. It's always someone else's fault
  3. Is always critical of other people's development or engineering work
  4. Empowers business users to select technologies or overly specify solutions without understanding the nature of the opportunity or problem and identifying scalable, supportable options
  5. Communicates in technical jargon or overly complicates the message back to a business user when responding to a question
  6. Fails to automate tasks and leaves significant manual steps in a technical solution
  7. Doesn't drive to become a technical expert. Does not read documentation. Fails to question vendors and consultants to ensure knowledge transfer on new technologies or solutions
  8. Allows meetings to go off agenda by bringing up issues that are only tangentially related to the topic being reviewed
  9. Doesn't collaborate with technology colleagues. Leaves issues lingering so that he or she can be the hero to resolve them
  10. Under invests in the time required to learn new technologies and solutions. Doesn't consider free resources to learn about a technology or practice. Wants training, but does not identify opportunities to leverage what they've learned.  

Agile Development

  1. Creates blocks and waits for requirements without engaging the stakeholder or proactively proposing opportunities, problems that need to be addressed, and solutions 
  2. Creates technical debt but does not itemize it in the backlog to be fixed 
  3. Only does what was requested and doesn't question members of the development team to make sure the requirement and solution are complete
  4. Fails to align solutions to target architectures, data models, and other standards. 
  5. Doesn't check in code into version control daily. Checks in code that breaks the build.
  6. Thinks xx and other non-descriptive variable names are acceptable in code
  7. Over engineers solutions and inflates estimates 
  8. Holds back and under commits to sprints. Does not push the extra mile and over commit when there is a business need
  9. Doesn't provide documentation, training, or other knowledge transfer to ensure colleagues can support the technologies he or she developed
  10. Treats quality assurance, testing and security as an afterthought and doesn't bake these paradigms into designs.  
  11. Doesn't implement unit tests, performance evaluations, or other test driven practices to ensure that code is reliable and functioning properly
  12. Skips or does not participate in standups, commitment, retrospectives and other agile meetings


  1. Makes systems changes without following through and insuring it had the desired impact 
  2. Fails to regularly communicate status when resolving a critical issue 
  3. Thinks the application is working normally because the systems are fine and network, cpu, and storage monitors are all green 
  4. Chases rabbits when trying to diagnose performance issues without reviewing logs and metrics to guide efforts to areas of higher importance
  5. Says a system is "ready" when the underlying application hasn't been fully installed, configured, and connected to operational and support systems
  6. Claims a systems capability such as backups, snapshots, or disaster recovery is available but doesn't create and test procedures to ensure they are operational
  7. Doesn't participate in the agile development process until the version is near-ready for release.
  8. Fails to listen to business users on the context and priority of their service desk request. Prescribes technical answers and solutions that does not fully address the business problem facing the user.
  9. Doesn't follow standard builds, deployments and configurations.
  10. Doesn't track utilization and other capacity trends to ensure that policies, procedures, and system resources are realigned when required.
  11. Considers the cloud and SaaS solutions as competing technologies to on premises solutions and does not provide sufficient operational solutions or problem resolutions around them

continue reading "33 Bad Behaviors of Agile Developers and IT Operations"

Tuesday, May 05, 2015

Agile Culture - Are You Developing Solutions or Solving for Business Opportunities?

Here is the hardest problem for a performing agile development team -

Can you build me something that does A, B, and C for Users X and Y and have it completed within the next couple of weeks

What is the problem with this form of requirement? Many of you might start with the obvious that you need more details around A, B, and C to gain a shared understanding with the product owner or stakeholder of their requirements. Then, some of you will focus on "couple of weeks" and recognize that the product owner is trying to fix both scope and timeline which needs to be managed, ideally through agile estimation and prioritization. Others will also guess that the team already has a backlog and this requirement is probably an Epic that needs to be prioritized and planned for a release.

But this is not my fundamental problem with this form of my requirement.

What Problem or Opportunity Are You Solving for and Why?

The problem I have with the requirement is it's asking the development team to implement a specific solution. There's no statement of the problem, opportunity, or value that will help Users X and Y. The product owner has effectively decided on a solution and is only asking his or her technologists to go out and implement it.

I listed this issue on my 20 Bad Behaviors of Agile Development Product Owners and if I ranked them, #5 Defines solutions, can't state the business problem would be one of my top bad behaviors. For some product owners, they struggle with the effort and discipline required in separating problem from solution and collaborating with their development team on them.

I should point out that best practices in agile story writing usually starts with defining it from a user's perspective. As User X, I want to be able to do A, B, and C so that I can enjoy benefits Z. Also, agile coaches will help teams define product visions and release targets to better express and align on business value.

So there are mechanics in the agile process at the Vision (macro) and Story (micro) level but the issue as I'm describing it is more of a culture and collaboration problem.

Getting a Business Problem or Opportunity Defined

One reason getting the business problem or opportunity defined is that it can be harder to abstract especially when the Product Owner has to get feedback from customers or sales. It's easier for them to validate if A, B, and C meet customers' needs and a much more difficult dialogue to get at the real opportunity and value captured.

Therein lies a simple solution to this issue. If the Product Owner Thinks the Dev Team should only be consulted once the product is defined (bad behavior #6) then it's too late. They brought the team in too late and the product owner has already developed a strong opinion on a solution. Developers often have to back pedal there way to discuss alternatives, quality requirements, architecture considerations, and cost constraints.

Transformational Advice

Here is my advice

  • Bring the dev team earlier 
  • Let some of them hear directly the voice of the customer. 
  • Draft the business problem together 
  • Partner with them on solutions  
  • Formulate a statement on quality objectives
  • Consider multiple solutions 
  • Prototype and test with customers

continue reading "Agile Culture - Are You Developing Solutions or Solving for Business Opportunities?"