Even as I write this proposal, there are hundreds of organizations looking to scale Devops across the enterprise.

This objective of this talk is to share the valuable lessons imbibed in the last 18 months from scaling Devops across the IT organization. I would be touching upon the following topics:

1. Using maturity models as training wheels. Initial top down approach to set the expectations, enable strategic alignment (cascading IT level goals to segments and services) and set the context ("why")

2. Implementing Strategies for enhancing cross geo collaboration across distributed teams - Sharing the pain, common backlog, collocation vs distribution etc..

3. Leveraging Geo based accelerators for training, building awareness and proliferating communities of practice

4. Monetary and non-monetary means to recognize and reward Devops behaviours, - sharing success stories, proliferating change agents and promoting light house teams

5. Standardized metrics package limited to 5-6 metrics to transition to an outcome based model

6. Centralized coaching and mentoring to focus on principles, enable and empower teams

7. Planning and Investing in tools and technologies around automation, predictive analysis, monitoring and infrastructure to enhance predictability and stability

We now realize that transformation is not about just changing behaviours and attitudes but more about creating purpose through backlogs, empowering teams and accelerating business value delivery.

We have covered a lot of ground in the last 18 months. Keeping aside the quantitative metrics, the following is what gives us the confidence that we are on the right track is:

1. All work items to be implemented gets added to the backlog

2. Prioritization of work items is done based on business value

3. Enhanced recognitions inter and intra team and peers across Geos enabling a collaborative ecosystem

We have a long way to go, but the road ahead looks promising.

Introduction and context setting: 

Everyone has heard the oft-quoted maxim about leadership from ancient Chinese philosopher Lao Tzu, legendary founder of Taoism and author of The Tao Te Ching:

“A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves.”

In the words of Michael Shinagel from Harvard University:

“Leadership is a protean art that defies a simple definition. It can take the form of a brash “command and control” style epitomized by General George S. Patton: “Lead me, follow me, or get out of my way.”

Or it can take a subtler form of leadership as exemplified by Nelson Mandela: “It is better to lead from behind and to put others in front, especially when you celebrate victory when nice things occur. You take the front line when there is danger. Then people will appreciate your leadership.”

Perhaps President John F. Kennedy put it best when he observed, “Leadership and learning are indispensable to each other.” Leaders learn to become leaders, and they continue to learn in their role as leaders.”

Learning is indispensable to leadership and coaching is one of the least focused or talked about aspects of leadership. Coaching helps leaders catalyze individual strengths towards peak team and organizational performance. In this proposal, I would like to share and  dwell upon the lessons which enables leaders to become effective Change Agents and enable mindset changes that are an essential aspect of every agile transformation.

Learning 1: Remove self limiting beliefs and become more self aware

1.1 Never limit yourself by the past

Early in my career the CEO of the organization that I worked for shared with us what is popularly known as the “Elephant Trick” in one of the open forums. This goes like:

“The best advice I ever got was from an elephant trainer in the jungle outside Bangalore. I was doing a hike through the jungle as a tourist. I saw these large elephants tethered to a small stake. I asked him, 'How can you keep such a large elephant tied to such a small stake?' He said, 'When the elephants are small, they try to pull out the stake, and they fail. When they grow large, they never try to pull out the stake again.”

Time and again, I have found this insight inspiring whenever I had to influence myself or the teams that I worked with to move out of the comfort zone, go beyond the past failures and expand the horizons. This is at the core of what is better known as “Growth Mindset” these days.

I always nudge my teams that while it is my job to enable them to move out of the comfort zone and challenge the status quo, it is their job to tell me when they have reached the limit and need help. Failures are fine as long as they lead to learning experiences that helps shape a better future. This approach helps teams to let go of their limiting self beliefs, past failures and harness the power of a “Continuously Learning Mindset”. 

 1.2 Perception is reality

There are very few of us who are not surprised by the 360 degrees feedback that we get on an annual basis.

Whatever may be the reality, how people perceive us is what determines the way they interact with us on a day to day basis. We create perception through every action that we take or do not take. As we go about the business of carrying out our life, people will make judgments about our appearance, personality and capabilities

It is very important to constantly communicate with the stakeholders and be consistent in “Doing what you say and saying what you do”. Providing and seeking feedback regularly helps reduce the gap between perception and reality. 

Learning 2: Change behavior, not culture

We often hear that employees are irrational in face of change and find all possible reasons to avoid it. I do not agree with same. Majority of the times, the irrational ones are the organizations who set objectives, processes, job description in a way that people stick to them and are surprised that they resist while being exhorted to do the opposite.

So, where does real change start ? Real organizational change starts from changing behaviors. Behaviors in turn are triggered by performance management, rewards and recognition systems. It is important that are 

As Eliyahu Goldratt mentioned ““Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way… do not complain about illogical behavior…”

It is also important to recognize the behaviors that lead to the outcomes as much as we recognize the outcomes themselves. This helps shape the organizational culture that we would like to build and is at the core of building light house teams with high trust and ownership that set the trend for the rest of the organization.

Learning 3: Asking people to collaborate does not foster collaboration

An example that I recollect is of two teams who had tangential goals and were asked to collaborate. One of the teams was measured on identifying the maximum number of defects and errors whereas the other team was measured on the velocity of the deliverable and Time To Market (TTM). As many would agree, similar environment prevails between development and QA teams in most organizations.

Lesson learnt is “Don’t ask people to collaborate if they know that, in the end, there will be a winner and a loser. “ At the heart of most team / organizational dysfunction lies a non-aligned goal setting, performance management or rewards and recognition system.

So how then do we make teams collaborate and achieve synergies. This is where the power of “Shared Vision” kicks in. Measuring teams on a common high impact outcome helps them to collaborate with each other. I realized that measuring teams on a common goal of Time To Market (TTM) and business value creates excellent collaboration between development and QA teams. 

Learning 4: Develop clarity of thought

Wherever there is clarity of thought, there is also commitment, focus an flow. It is essential to focus on the basics like creating trust and ownership in the team, getting and acting on early customer feedback, writing excellent code, automating repetitive processes, thorough regression testing and creating continuous incremental business value. Most of the times people chase the latest fads like mob programming, latest technology without really understanding if that is really required to solve the problem on hand. 

It is also important for the leader to ask the right questions. Leaders should focus on “why” people do what they do vs. “what” they do. Asking the powerful question “why?” forces people to think deep. They can then peel back the layers of excuses and get to the root cause of the problem. For example, if employees have failed to meet a goal and are asked “why” questions rather than “what” or “how” questions, they might give responses like, “I didn’t prioritize my time.” So, the leader must then go farther and ask, “Why didn’t you prioritize your time?” When the employees say they have too much on their plate, the leader must ask “Why?” once again. The final answer: These employees are working on many tasks and cannot distinguish between what is and what isn’t a priority. With the real problem revealed, the leader can now take appropriate action, perhaps setting up time to help them prioritize their many tasks.

 Learning 5 :Creating teams with "Purpose"

Most of us are aware of Dr. Viktor Frankl  who became well known to the world through his book "Man's Search for Meaning" which is devoted to studying, understanding and promoting “meaning.”

In his words, as given below:

"Everything can be taken from a man but one thing: the last of the human freedoms—to choose one’s attitude in any given set of circumstances, to choose one’s own way.When we are no longer able to change a situation, we are challenged to change ourselves. Between stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom."

“He who has a why to live for can bear almost any how.” — Nietzsche

Wherever people understand the "Why" behind what they are working for, this automatically creates an environment of high commitment, pride in work and ownership.  Storytelling is also an effective mechanism to help people relate to the situation on hand and engender higher levels of involvement.

Usage of purpose alignment matrix and four questions (who do we serve ?, What do they need and want most ?, What do we do better than anyone else to meet those needs and wants ?, What is the best way to deliver these products / services ? ) helps establish the team's purpose

While compensation is definitely a hygiene factor, it does not by itself motivate people toward better performance.I have personally found Dan Pink' s model of Purpose, Autonomy and Mastery quite effective when deployed at the work place.  

Learning 6: Steer clear of common  decision making bias and pitfalls

 As leaders, we should be aware  of and steer clear of the following common biases. I will cover these in more detail during the talk with specific examples.

• Attribution bias
• Zero risk bias
• Recency effect
• Information bias
• Ostrich effect
• Overconfidence

Over the years,  as I worked with several teams, I observed that everything that we do to perform any activity in an efficacious manner, whether it is as simple as fixing a bug or building something as complex as a space craft can be broken down into  three distinct patterns - "Why", "What" and "How" .

This is what I would like to term as W Squared H approach to lean product development and it is an attempt to blend the best practices from lean startup with the traditional time tested lean development methodologies.

The aim of this talk is to provide an insight into proven tools and techniques  that can be leveraged to create competitive advantage and customer delight through reduced time to market and faster value delivery. The focus is on a cross section of key lean  practices that can be leveraged for  better efficiency and effectiveness in the product development life cycle by enabling teams to build the right thing the right way.

Some of these practices will be elaborated with regard to the “what”, “where” and “how” and typical benefits that can be harvested.

Sustenance is the key to harness the full potential of world class practices and processes. Hence the final part of the presentation would also cover lean leadership and sustenance techniques that work.

Given below is a snapshot of the topics proposed to be covered during the talk.

Introduction:

• 14 lean principles (philosophy, process, people and partners, problem solving)
• Challenges / Barriers to lean product development
• Value vs Price
• Five steps to Value

 Why:

• Purpose Alignment Matrix and strategies for "Parity", "Differentiating", "Partner" and "Who Cares"
• Four questions 

What:

• Lean Product Process (Achieving Product  Market fit)
• Design - Build - Learn
• Problem Space vs Solution Space
• Kano Matrix
• Importance - User satisfaction matrix

 How:

Methodologies to eliminate waste, create flow and strengthen the weakest link

• MVP and value proposition
• Managing dependencies - Design Structure Matrix
• Value Stream Mapping
• Busting the 6 myths of product development
• Visualizing workflow and identifying bottlenecks 
• Creating flow and pull
• Reducing cost of change
• Achieving perfection - iterating to strengthen the weakest link 
• Optimization - Orthogonal Arrays and Risk Based Testing
• Benefits from lean product development

 Sustenance

• 9 keys to execution excellence
• Lean leadership

There are so many organizations and product teams that are embracing agile implementation methodologies as a means to accelerate product development for competitive advantage and customer delight. Agile is now more than a fad or a buzzword.

Despite all this pervasiveness and penetration, there are only some teams for whom agile works well, whereas it doesn't work so well for some of the other teams and it fails for the rest. 

But, is the problem really with adopting agile or is it something else? After all, agile is a mirror.

As Leo Tolstoy once said, "All happy families are alike; each unhappy family is unhappy in its own way.” There is a lesson to learn from every failed implementation.

From the 9th "State of Agile" survey done by VersionOne in 2014, in cases where agile projects were unsuccessful, 44% of the respondents pointed to lack of experience with agile methods.

Drawing from my experiences through my journey as a lean agile coach, this is an attempt to collate the anti-patterns (sins) associated with "lack of experience with agile methods" within the teams implementing agile and possible solutions (epiphanies) to overcome them. I believe that addressing these anti-patterns and preventing them from happening in your teams would significantly enhance the probability of succeeding with your agile implementations. Establishing the purpose and aligning the teams with the organization strategy is one of the key determinant of success. Due to time constraints, I would be focusing on 3-4 anti-patterns (points 1,7,8,9)  that are commonly seen while touching on the rest of them briefly.

 Details are given below:

1. Square pegs in round holes- These are role anti-patterns and arise by looking at Scrum Master / Product Owner as positions to fill rather than identifying and assigning the right person for the job and abrupt transitions from PM / architect to SM / PO creates this anti pattern. It is important to ascertain the fitment and identify the right person with the attributes of a servant leader who can influence the team without authority, empathize, ask the team the right questions which would empower and enable them to become more self-organizing and step back when required. In cases where a transition is involved adequate training / coaching needs to be provided to smoothen the transition.

2. Ineffective retrospectives - Retrospectives are treated more as a ritual with no feedback loop to the planning process. Ineffective retrospectives are good at addressing the person and not the problem, creating actionable without owner(s) and timelines, have no focused outcomes and create a "blame game" culture.

3. Sub-optimal local execution - This is reflected in product teams / modules / component not aligned at the global / program level and is primarily due to misalignment of the teams during planning, no vertical slicing, poor dependency management,  inability to create cross functional teams, no single product backlog, infrequent touch points across the teams with no day to day interaction. This typically results in teams following the sprint cadence but not creating any working deliverable at the end of the sprint.

End to end optimized execution is possible only through creation of flow across the entire product line. As a first step, it helps to visualize the workflow and understand the work in progress across the various sub-systems to surface the bottlenecks. Cumulative Flow Diagram (CFD) is one of the powerful tools that help identify bottlenecks across the system.

Some general techniques that help address bottlenecks are identifying the right features (Kano model and user satisfaction matrix) and then vertical slicing to create a working deliverable every sprint, having a single Chief Product Owner (Scaled Scrum) who owns the overall product backlog and ensures priority and value alignment with each team's backlog, synchronizing the iteration time-boxes to ensure that dependent user stories are delivered in the same sprint as much as possible, investing in building relationships and trust among teams (investing in kick-off meetings and face to face engagement), creating a scheduled daily cadence for points of alignment like daily scrum of scrums (weekly inter-team sync-ups would be a killer for teams working on 2 week sprints), usage of tools like Design Structure Matrix (http://dsmweb.org/) for the right development sequence during planning / accurate impact analysis and complexity assessment alleviates this anti-pattern to a large extent.

Other aspects to address include the team structure and alignment. Executing cross skilling plans levels out workload and integrating business + dev + QA ensures that the right product is built right and reduces failure load significantly.

4. Dysfunctional team  - This typically happens due to trust deficit. There is typically no daily engagement with the team and team is comfortable with conflict avoidance. Understanding the team (Use tools like Pat Lencioni's 5 dysfunctions of a team), managing conflicts effectively, creating conditions for constructive confrontation, rewarding team collaborative behaviors goes a long way in creating trust, confidence and collective responsibility.

5. Dis-engaging Daily Standups - Typical anti-patterns here include scrum meetings that overrun significantly beyond stipulated time, team members reporting status to the Scrum Master and not the team, impediments not raised in the meeting, dis-engaged team members. Visualizing the work, raising and tracking impediments, being sensitive to the time zone differences and accommodating them, investing in technology that helps enhance the engagement / involvement levels of the complete team helps make the daily scrums more effective.

6. Unaligned Process model - Team members frequently pulled into firefighting and production support activities with no regard to the commitments made. There is a need to introspect if time boxed sprint is the right way to go for teams in this case or would a different approach like Scrum+ Kanban (ScrumBan) work better ? There are also cases where heavy weight ALM tools are used for short duration engagements or small teams just because of the availability, without any training or regard to the ROI.

7. Product Owner - Team misalignment: This is typically manifested in busy product owners (Example -: product owner spending time in too many  discussions with the client, Product Owner for multiple teams) for whom this is an additional responsibility apart from their day jobs, mismatch between the product owner's expectations and the team's expectation, disruptive product owners who do not appreciate or understand the team's challenges, team's velocity not factored in release planning by the product owner. Ensuring that a product owner is not assigned for more than 2 teams, business analysts in the team interfacing with clients to see what the market needs leaving the responsibility of the technical product to the actual product owner, proxy product owner who is empowered to take decisions in the product owner's absence are some of the strategies that ensure enough bandwidth is available for the POs to collaborate effectively with the product team and focus on effective product delivery.Appropriate budgeting for PO during the pre-planning phase, sensitizing the product owners through more face time with the team, identifying  chief product owners for alignment across multiple teams (scaled scrum), proxy product owners are also additional strategies that can address this situation.

8. Not building the right thing - As Drucker said "There is nothing so useless as doing efficiently that which should not be done at all". . Appropriate widely used techniques / frameworks (Value Stream Mapping, Value-Risk mapping, Risk Based Testing, Design Structure Matrix, Product-Market fit decision frameworks, Kano model) for identifying the right thing to implement, prioritize and eliminate waste would help tackle this antipattern.

9. Cultural anti-patterns - Typical issues observed here includes -Teams not aligned to the organizational goal / purpose of the program,  non-collaboration across teams, offshore team treated as a "B" team,lack of T shaped skills, inappropriate performance / R&R systems that reward individual success over team success, irregular or inconsistent sprint cadence, student syndrome, using velocity as a tool to compare performance across teams, abrupt transition from project manager to scrum master role, management looking at agile as a tool to overwork the teams, poor ALM tooling strategy and non-alignment across the teams.

Why is alignment important ? Because one of the important components of ownership is knowing "What to own ?". In surveys with the top management misalignment of the team's goals with the organizational goals comes out as a top response.

Some symptoms of a poorly aligned team include: poor or failed execution, lack of clarity about priorities, low morale, absence of healthy debate, lack of ownership or follow through, underground communications (gossip, “us versus them” thinking)

Usage of surveys like the team alignment questionnaires, Scrum Butt questionnaire, team assessment versus the 12 agile principles surfaces points of mis-alignment and dysfunction across the teams

Some solutions to address cultural dysfunctions include usage of purpose alignment matrix and four questions (who do we serve ?, What do they need and want most ?, What do we do better than anyone else to meet those needs and wants ?, What is the best way to deliver these products / services ? ) to establish the team's purpose, creating cross-functional teams that can get to “done” in each location, recognizing and rewarding adaptive collaborative change behaviors (cross skilling, taking initiatives in supporting team to overcome impediments, helping others cross skill, breaking boundaries for effective problem solving) to reinforce these behaviors,  assessing current project managers and ensuring an effective transition into agile roles through 1:1 coaching (for transforming  smoothly from command and control to servant leadership), effective management of time zone differences in distributed teams to ensure appropriate rotation of meetings / discussions so that one of the teams does not burn out, top down approach to sensitize management and make necessary changes to the organizational structure and career roadmap  for accommodating agile roles like Product Owner, Scrum Master, agile program manager etc.. , adopting objective metrics like Time to Market (TTM) and business value accrued to measure effectiveness.

As Eliyahu Goldratt once mentioned "Tell me how you will measure me and I will tell you how I will behave". Therefore, look into your performance systems first if you come across any dysfunctional behaviors. One cannot expect a person to display collaborative behavior, if the performance system encourages and rewards individual success over team success.

10. Surfeit of Metrics  - Team tracks too many metrics that are not relevant and are inherited from waterfall mindset. There is also an obsession for effort tracking at the individual level and % complete’s. Burn-up charts, velocity, committed vs achieved ratio, defects per sprint are just enough metrics for effective tracking.

11. User story anti-patterns - Teams do not put in efforts to refine the product backlog as it is seen more as a cost than an investment. There are multiple product backlogs and definition of ready is not agreed between the PO and the team. This results in large user stories that cannot be completed in a sprint, wait times for clarifications and things getting put on hold a few days after implementation due to lack of adequate inputs. Agreeing on a Definition of Ready (DoR) and coaching the team / PO on patterns for splitting user stories helps overcome these barriers

12. Agile Manifesto Delusion - This typically manifests as no documentation, no Definition of Done, multiple disruptions during the sprint to accommodate changes etc... Helping teams understand and interpret the agile manifesto and principles in the manner in which they were intended creates clarity and helps obliterate this anti pattern. 

At the end of the day, it is all about delivering valuable working software in an incremental manner. Hence principles should always take precedence over practices and tools. We, from the agile community have a big part to play in helping to realize the above and breaking the above barriers for successful agile adoption. 

Studies indicate that only approximately s40% of the projects meet schedule, budget and quality and 60% of a project's effort is spent in rework. Surveys conducted by the Boston Consulting Group show that in complex organizations (20 percent of organizations) managers spend 40 percent of their time writing reports and 60 percent coordinating meetings. According to the Economist Intelligence Unit, about 60 percent, or 3 out of every 5 employees, feel they do not have the right information. Putting the above statistics in perspective, visualizing work to identify bottlenecks and improve flow, enabling access to right information, reducing re-work can go a long way to enhance productivity / throughput leading to excellence on schedule, budget and quality goals.

This case study shares the experience from a large Software Application Maintenance project in the package space in the manufacturing domain. The team faced the twin dilemma of cost of delivery reduction from the organization and customer expectation for increased “back office” ticket throughput.

Kanban and TOC with it’s focus on incremental, evolutionary and people centric approach to visualize workflow, surface bottlenecks,  engaging the team to improve flow was a natural choice to enable cycle time / throughput improvements. The constraints and bottlenecks that surfaced from workflow visualization through Kanban boards were addressed by:

• Reducing multi-tasking through WIP limits, planning / prioritization policies, identifying and resolving high WIP patterns through usage of Cumulative Flow Diagrams (CFD) and Root Cause Analysis (RCA)

• Streamlining demand to improve flow

• Elevating constraints through cross skilling, mistake proofing, automation

• Standardization of planning, operating procedures

• Fostering collaboration and learning through mentoring, pairing, knowledge management

• Iterating through Plan -> Do->Check->Act (PDCA) cycles for course corrections, as required

Effective deployment of Kanban / TOC led to 62% reduction in effort per ticket, 83.4 % increase in throughput for back office tickets and 30 – 35% reduction in average cycle time. Cost of delivery was reduced from 36.8% to 25.1%. There were savings of 1.33 mn USD for the customer from the improvements made and sustained.

Lean levers helped derive significant competitive advantage by maximizing program goals, inculcating a culture of continuous improvement leading to high employee engagement through better work-life balance and high customer satisfaction.

Executing add-on Application Development (AD) projects end to end is quite challenging. More so, if the same is executed under risk-reward model. According to an IBM study, only 40% of projects meet schedule, budget and quality goals. 20 to 25 percent don’t provide ROI and up to 50 percent require material rework. 

With competitive pricing and cut throat competition eroding margins and denting market share, cost of delivery reduction with best in class quality has become an imperative for any service company in the IT outsourcing space.

This case study shares the experience of an AD project (team size 40) in the Insurance domain completed over a period of 9 months (including warranty phase), with a geographic spread across 4 different locations. The team had end to end responsibility right from requirements gathering to System Integration Testing. The add-on functionality developed was rolled out to 5 states spanning 2 different releases. The team leveraged LEAN Six Sigma techniques (DSM, OA, Visual Controls, Mistake Proofing) for culture building, effective change management, early feedback, rework reduction through effective in-process defect reduction and doing things right the first time, resulting in increased customer goodwill, reward payments, enhanced business and high employee satisfaction. The project was flawlessly executed under the risk reward model with best in class quality, maintainability and scalability within the specified schedule.