Agility: 8 Pillars For Building Self Organizing Teams

Last week, I was invited to speak as a panelist at Agile Carnival, Chandigarh where I expressed my thoughts on Agile as a method and as a mindset. Agility in our approaches is one of the most potent ways to deal with the challenges of a constantly changing world.

Here is the summary of a few thoughts I shared (and a few more):

  1. Agile is not just a method or process, but a mindset. Which also means, if your organization wants to be agile (and strategically nimble footed), you have to invest in building a culture of agility.
  2. You need to build a system of management methods, rituals, processes, tools and motivation where people are more likely to exercise their choice of doing a good job versus doing a great job. Their discretionary effort is so vital for your success. If you are aiming to build teams that are self-organizing, this is even more crucial.
  3. To be a part of a self-organizing team, people require maturity, skills and expertise to deal with technical challenges and manage conflicts constructively. Without required technical and functional competence, team will just not be able to take decisions to move forward.
  4. Narrowly focused reward programs kill self-organization within teams. When people have narrow and conflicting goals, they will do everything to meet their goals and yet, system might fail. Setting up systemic goals are vital to encourage collaboration (everyone wins when the system wins) rather than competition.
  5. Self-organizing teams also need a leader (read coach) – only that the role of a leader is to guide self-organization and clarify the direction relentlessly. A leader enables self-organization between team members and plays the role of mentor or a coach to the team. For this, leaders have to adopt an abundance mindset and give up on old ways of leading others through command and control.
  6. You cannot manage what you cannot measure, it is said. But you only get what you measure. We need to measure right things for right things to happen. E.g. if you only measure utilization, you may get high utilization but lower efficiency.
  7. Learning – collective learning – is the currency of self-organization in a team. The job of a leader is to establish forums where collective learning can happen. I have seen leaders who use forums like technical reviews and retrospectives to guide collective learning.
  8. Prioritization is at the heart of self-organization. When you have too much on your plate, you cannot deliver excellence. I have seen so many teams  derail when multiple and conflicting priorities don’t allow them to focus. Lean methods like Kanban therefore suggests that we limit the work in progress (through effective prioritization) and make the flow of work visible.

Over to you: What have been your experiences in building a self-organizing and agile team? If you were on the panel, what would you have shared?

Optimize the Whole

When we think in parts, we improve in parts. Most of the business improvement is the game of ‘sub-optimization’. You optimize pieces without looking at the whole.

When a customer reports problem with your software, you do an incidental root cause analysis and address the code quality problem. You deploy tools, introduce new processes, measure constantly and yet – a few months later, you encounter a similar problem.

But when you look at the whole system, you might figure out that the real root cause is in something which is immeasurable yet important – may be, collaboration with other teams or how you sell. May be, inefficiencies rooted in how you support your customers after product is delivered.

We optimize the silos and the whole misses our radar. If ‘customer centricity’ is one of your key values, you should consider optimizing the whole customer journey with your organization – not just your development processes.

Often, we also optimize that which is measured. If your metrics are narrow, you will never be able to focus on systemic metrics that may really help your business and the customer.

Here are a few important things to consider when you optimize the whole:

We need to cultivate “a discipline to see the wholes, a framework for seeing interrelationships rather than things, for seeing patterns of change rather than snapshots

  • Focus on Value Stream. Value for customer is created in a series of interactions between various processes that starts right from first contact with the customer. Value stream mapping is a lean tool to identify a series of events right from conception to delivery of product or service.
  • Define what “complete” system means. Too often, we think of complete product as a set of completed features. For customers though, complete product is an experience they receive through each interaction with the organization. It helps to define what ‘complete’ means.
  • Measure Right. When you have narrow functional metrics, people in each function will work  hard to achieve their goals and yet, organization will not realize benefits of having such metrics. However, if you have more systemic metrics (and rewards) where people win only when the system wins, it aligns everyone to the same set of goals to ensure that ultimately, customer wins too.

Sub-optimization in organizations is a thinking problem. When you fail to see the whole, you undermine your capabilities as an organization.

And this may be the precise thing that holds you back from delivering a superior performance to your customers.

Book Review: Agile Excellence For Product Managers – A Guide to Creating Winning Products with Agile Development Teams

Agile_Excellence

The game of software product development is the one of adding value to the businesses and customers.

With rapid changes in business environment, typical waterfall SDLC fails to deliver value, because by the time the scope is developed, business requirements change!

Adoption of Agile Development Methodology by software product managers is steadily increasing because Agile embraces business change into products.

I recently read the book “Agile Excellence For Product Managers” by Greg Cohen. This book is a guide to develop winning products with agile development teams. When most of the books on Agile focus on the process, this book focuses on the product manager’s perspective of how Agile process should be managed. The book also has a small section that touches upon XP and Lead Software Development.

I have been studying Agile for over a couple of years now, and have also implemented Agile in a number of  projects. I still found this book useful because it also deals with issues of organizational agility and importance of leadership in implementing Agile.

Agility is a mindset, more than just a process. For this very reason, adopting Agile means an organizational change in mindset. Agile is a shift from typical command-and-control structure to a trust based, highly accountable model of software development.

Bottom line: If you are a product manager who is keen to explore Agile or is already using Agile, this book will help you dig it little deeper and gain better understanding.