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?"

Monday, April 27, 2015

20 Bad Behaviors of Agile Development Product Owners

I've worked with some very strong Agile Product Owners, others that needed a lot of help transitioning from BRD centric waterfall product management, and others that have strong backgrounds in other product roles (product strategy, management, or marketing) and are new to agile product development. 

I've partnered with many successful agile product owners that have launched innovative products, instituted new technologies and transformed business processes. But even with the strongest, most successful ones I've witnessed bad behaviors from time to time.

Agile Product Owners Behaving Badly

So here are some of the destructive behaviors of a product owner. I've compiled the list so that product owners can review and reflect on their own behaviors and practices and for Teams to point bad behaviors when they surface. 

Bad Behaviors

  1. Doesn't show up for demos 

  2. Never thanks the Team - always wants more

  3. Blames the agile practice and the Team when things go wrong

Issues in Product Definition and Requirements

  1. Anti - MVP. Does not define simple products. Focuses on the edge use cases and complexity

  2. Defines solutions, can't state the business problem

  3. Thinks the Dev Team should only be consulted once the product is defined

  4. Angered over missed requirements, but doesn't read the stories

  5. Still writes the BRD, then expects the Team to translate them to user stories

  6. Under-invests in reviewing usage and performance data to determine product priorities

  7. Lives outside the agile tool and process

  8. Sets and communicates the release timeline without consulting the Team

  9. I've delivered the product roadmap, please send me your project plan and costs

  10. Drives teams to brainstorm solutions for feature/epics that are not formally prioritized

Difficulties Partnering with Technology Teams

  1. Selects technologies (including SaaS) and expects the IT Team to implement them

  2. Expects Spikes (stories for research and development) to succeed all the time

  3. Under allocates time to tech debt, research, and documentation

  4. Doesn't formally prioritize and shifts priorities in the middle of sprints

  5. Pushes the team to compromise on technical standards (security, data governance, IT Ops)

  6. Holds teams accountable to early story estimates and circumvents estimation process 

  7. Attempts to micromanage and wants granular details on how stories are being allocated to team members

If you've experienced any of these with your product owners or you'd like me to elaborate on any of them, please comment!

continue reading "20 Bad Behaviors of Agile Development Product Owners"

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 "