Posted on

How Do You Turn Around A Team Not Performing Well?

The first thing needed is an assessment of what’s wrong. My advice is to meet with each member of the team individually, make your own assessment of the information you are receiving. A few key dimensions to collect and assess are team structure, individual assignments and roles (whether the team has the right skill sets, are they motivated in their roles and are there any prevalent bad attitudes), and leadership style within the team. Also note the current success and failures  of the team.

What has worked well for me in the past is to define a mission statement for the team – what are we trying to do and why? Each member of the team should be able to state and defend the mission and why its critical. A shared understanding and buy in is critical for the team to rally around and cooperate. Remember the Star Trek Enterprise episodes always started with their mission statement – “Space, the final frontier. These are the voyages of the starship Enterprise. Its 5-year mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no man has gone before.”

Define SMART (first defined at GE) and Stretch goals. Smart goals are specific, measurable, achievable, realistic and timeline based. Stretch on the other hand may appear to be more than possible, but are the ones that spark remarkable innovations.

Setup team norms that ensure psychological safety (Charles Duhigg – Smarter, Faster, Better – The Transformative Power of Real Productivity). The following is an excerpt from the book that describes this concept and some of the other critical building blocks for a high performing team:  A team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.

1. Teams need to believe that their work is important.

2. Teams need to feel their work is personally meaningful.

3. Teams need clear goals and defined roles.

4. Team members need to know they can depend on one another.

5. But, most important, teams need psychological safety.

Where “Psychological safety” is a shared belief, held by members of a team, that the group is a safe place for taking risks. It is a sense of confidence that the team will not embarrass, reject, or punish someone for speaking up.

Next address the tactical issues of failures and risks. Secure stakeholder agreements to ensure that targets are achievable. Reassign or repurpose team members with bad attitudes.

Some general principles that have helped me throughout my career are as follows –

  • Keep criticism private
  • Roll up your sleeves and get in the trenches
  • Achieve short term wins; Praise achievements and celebrate
  • Inspire and motivate – “We can and We will”

Finally measure what you value and put it in a cycle for continuous improvement.

For example, for an IT team, the metrics to measure may be the following:

  • Cadence of delivery
  • Delivery throughput
  • Quality of code delivered
  • Stability of the application/platform/system
  • Scalability
  • Usability measure
  • Business continuity
  • TCO – total cost of ownership

While for a product team, you may want to measure and improve these:

  • Effective product lifecycle management
  • Product market position
  • Rate of new / modified products being introduced
  • Success rate for new / modified products
  • Ability to deco/sunset loss making products

Or for an Operations team, the following may be relevant measures:

  • Cost per unit work
  • Quality per unit work and rework %
  • Risk mitigation/avoidance and quality tolerance
  • Average turnover in the team and morale

As always, feedback is always welcome…

Posted on

How To Measure Delivery Effectiveness For An IT Team

Common measures that should drive an application or application development team’s metrics collection and measurement:

  • Cadence – how frequent and regular is the release cycle
    • the number of releases per year
    • the probability of keeping a periodic release
  • Delivery throughput – how much content (functionality) is released every release
    • measures such as jira counts weighted by complexity or size
  • Quality – number of defects per cycle
    • defect counts from a defect management system such as ALM or quality center
    • change requests raised post dev commencement
  • Stability – Crashes/ breakage/incidents around the application
    • Crashes
    • Functionality not working
    • Application unavailable
    • Each of the above could be measured via tickets from an incident management system like Service Now
  • Scalability – how easily does the application expand and contract based on usage
    • measure application usage variability across time periods – for e.g. we planned for usage to double for Rx fulfillment at mail order pharmacies during Thanksgiving and Christmas  holidays than normal weeks
    • application scaling around peak usage + a comfortable variance allowance
    • shrinkage back to adjust to non peak usage to effectively manage TCO  and use capacity on demand techniques
  • Usability – how well and easily can your users access or work the application
  • Business Continuity
    • ability to recover in the event of a disaster
    • time to restore service in a continuity scenario

In my opinion, some key pre-requisites that drive good metrics are –

  • Good design and architecture
  • Code reviews and design conformance
  • Scalability isn’t an after thought
  • Usability is designed before the software is written
  • Automated regression and functional testing

I have implemented versions of delivery effectiveness for my teams at both Morgan Stanley and Medco and contrary to most practitioners beliefs, its not that hard to do.  Please reach out if you want a deeper how to discussion.

Posted on

Org Design: Governance Vs. Delivery

Benefits of keeping governance and delivery functions together

Over the weekend, one of my ex-colleague reached out to me seeking advice on an org design question – should you keep  governance and best practices functions within a delivery organization?

My take: You can either keep governance functions within your best delivery unit or create a separate governance organization but it won’t be successful without assigning it some critical delivery responsibilities.

 

Here’s an example of what has worked in my professional experience:

At Medco, while running the BPM COE, I was tasked with creating a structure that could parallelize development. We had a massive transformation project, with a scale up target of almost 1000 developers at peak.

We had applications for various products – like mail order dispensing, point of sale adjudications, specialty pharmacy etc. These applications included common workflow capabilities like order processing, customer advocacy, therapeutic resource centers etc. These we chose to implement as frameworks. There were multiple scrum teams working on parallel development. We created a governance group – the Corporate Agile COE that was responsible for orchestrating application delivery across these framework dev groups (COE’s) and the application work station groups (BIACs).  In addition to governance, this group also had some critical enterprise framework delivery responsibilities like authentication and authorization, PHI data access controls, single sign on, personalization framework, and service bus client-server framework.

While governance is a full time job, without delivery responsibilities, it does not carry enough creds to be effective.

Why?

Architecture and Governance should not become an “Ivory Tower”: It needs to be grounded, practical and implementable; Incentives are aligned between delivery and governance, so governance principles are light, not onerous and implementable. And the best way to prove that a design is implementable is to give the person/team proposing it a chance to implement it using the same guidance; The aim for both architecture and governance should be to be simple, rational, elegant and not onerous so as to impact delivery.

Eat your own dog food – hence establish credibility when prescribing your solution: The group prescribing architecture principles is able to demonstrate through their own delivery that it works, hence establishing credibility when prescribing solutions.

Architecture not a scape goat for delivery: Other delivery groups cannot claim that the architecture is unimplementable and thus make the arch and governance group a scapegoat for failed deliveries.

 

 

 

Posted on

Responsibilities of a Product Owner

It is increasingly apparent that technology has become a large driver of business strategy. By providing new channels and mechanisms to interact with its customers, clients, partners and suppliers, technology is a key part of an organization’s sustainable competitive advantage. So its imperative for a product owner to not just understand the business landscape but also understand how he or she can use technology components as key artifacts in differentiating their offering.

Functional Responsibilities:

There have been a number of blogs which have focused on requirements that are intuitable, usable, simple and efficient. So I will not cover this aspect here.

Non Functional Responsibilities:

Security:

I cannot say enough on making sure your product is safe and secure for your users and their data and this focus is not only to comply with regulations like HIPAA but to stay out of the front page of the Wall Street Journal. Given the high profile breaches we have seen, it is imperative that your product has a plan for the following:

  • Encrypted data stores
  • Multi factor user authentication
  • Allow only encrypted access to your app or website
  • Std DMZ based protection for your applications
  • Regular security patch management program, software upgrades and periodic vulnerability assessment including pen tests and adhering to the OWASP Top Ten list.

Business Environment and Model Resiliency:

As a product owner you should keep an eye on the business environment and your competition, so that your business or application is not upended by a competitor introducing a game changing innovation or the market changing to be unfavorable to your product.

When I was working for a mail order pharmacy, we were able to use our functional components to rearrange the value chain and disrupt the pharmacy fulfillment market. Mail order pharmacy is a volume business and we used benefit plan design, formulary design and volume discounts to drive our profitability. The model did not involve engagement with a patient unless doing a coverage review or a generic substitution. We had implemented digitization of the prescription (i.e. separating the cognitive and the fulfillment parts of the process) to be able to route this to the most efficient pharmacist and/or robotic pharmacy to fill. Our competition – retail pharmacies on the other hand were local and a pharmacist at these retail pharmacy would have a one on one relationship with the patient. When we introduced the TRC (Therapeutic Resource Center) model, we were able to use our routing components to our advantage. We created these centers that were focussed on a specific disease condition (oncology, cardio-vascular, diabetic, neuro-psych, specialty etc.) and were able to route our chronic and complex patients’ calls and fills to these centers. The engagement that we got with these patients was a lot better than retail pharmacies, and we were able to drive mail order penetration using our plan designs by proving to our clients that we were able to bend the healthcare cost curves.

So when you are designing your product, keep your design flexible, so you can adapt if the environment or your competitor’s strategy changes.

Configurability:

Ask for your product to be configurable rather than needing code releases every time there needs to be a change. An example is the regulatory framework we designed for our on-boarding platform. Since my investment bank operates in multiple jurisdictions and there are frequent changes in regulations for any single jurisdiction; it was very beneficial for us to use a regulatory program framework with the rules extracted out of the application; These rules are user modifiable with the right approval workflow. This has given us a huge advantage in being nimble with regulatory changes and not have to wait for IT release cycles and change windows.

Modularize and Encourage Plug And Play Components:

When you modularize your system – like lego blocks representing various functions, you have the ability to introduce a champion-challenger competition between these blocks. This allows for increasing product innovation through constant improvements because of competition between the modules.

There are new capabilities being added every day in ML (machine learning) and AI (artificial intelligence). You want to have a flexible architecture so that you can plug these modules in anytime to improve the learning and adaptability of your apps.

Data Processing Variety:

Always design your application to be able to handle a multitude of data streams with different types of variety, velocity and volume characteristics. What I mean by this is your functional modules should be able to handle both structured (db, partner systems etc.) and unstructured data (say social media feeds/blogs). Given the growth in IoT devices, make sure you are able to source data from these devices and crunch them realtime to have a much more agile and realtime responses for your users.

Portability:

Be cloud ready – i.e. a portable application that is able to shift its compute and storage resources at any time. This is key for scaling up or from a business continuity planning perspective. Say you lose that data center that hosts your application. Are you able to port your application seamlessly to the disaster recovery compute / storage resources?

Platform Agnostic:

Technology obsolescence is a huge risk. Design your systems using std patterns, interfaces and open source components.  If one component goes out of its useful life or technical support,  it can be replaced by an equivalent functional component that isn’t obsolescent -this is not a question of “if” but “when”.

Scalability:

Your product needs to be able to scale up if there is a sudden rush of customer interest. It is useful to have a capacity on demand model, where you can dial up or down based upon market conditions. A number of cloud hosting providers have an elastic compute model offering that you can leverage.  For e,g, this blog site is hosted on an elastic offering with the ability to scale up or down depending upon demand.

 

SDLC Responsibilities:

Honest Broker for all Stakeholders:

A product owner is usually responsible for prioritizing the requirements from various business units and stakeholders into a single product. He or she must be an honest broker managing the interests and prioritization across these stakeholders in a fair, transparent and honest manner.

Promote Agile Development Practices:

Adopting an agile development methodology allows for iterative delivery where the development team has the benefit of frequent and constructive feedback and able to adapt to a dynamic market with rapidly changing demands.

Define Success and Measure Achievement:

Be able to define the metrics measuring application functionality, scalability and delivery before commencement of the scrum sprint. Should also be able to measure, communicate and put plans in place to address missing any of these goals.