We have a number of exciting workshops that are taking place during Agile India 2013 conference. One of the workshops that we are really excited about is ‘The Fastest Learner Wins‘ by Mary and Tom Poppendieck.

Both Mary and Tom are well known writers and speakers and probably need no introduction. Mary will be soon launching her new book ‘The Lean Mindset’ and will be sharing her some of her learnings during the course of this workshop.

We recently caught up with Mary and Tom and asked them a few questions to get a deeper understanding of what their workshop is about.

What does the title of your workshop ‘The Fastest Learner Wins’ mean?

Speed matters. Learning matters. Design matters. Speed, learning, and design – correctly balanced – are unbeatable.

Once upon a time, a company could hold on to its markets by doing what it had always done well. But today, a small group of smart people with a good idea can start up a new business anywhere in the world; they can leverage the internet and cloud computing to enter a market with a minimum amount of capital in a surprisingly short time. At first, these small upstarts are not seen as a threat by companies already in the market. But over time, the successful newcomers learn quickly and surprisingly often they have taken over whole markets with better, faster, cheaper offerings. The incumbents, caught in their successful past, usually find it’s too late to react.

What are the main ingredients that allow large companies to be able to sustain growth over time?

The average lifespan of a successful US company is about 15 years – much shorter than a career. This amazing fact might cause you to ask yourself: How can my company thrive over the long term? The answer is: Expect change and adapt to it. Our current organizations are strongly incentivized to continue doing whatever they have been doing in the past. But as companies grow large and the world changes, the only real path to sustained growth is innovation. The most innovative companies have learned to change their focus:

• From productivity to impact
• From predictability to experimentation
• From scalability to decentralization
• From making money to making a difference

What will be the key take away for the workshop attendees?

Attendees will learn strategies for improving their companies in the areas of:

1. Innovation
In a world where natural disasters and economic shocks have become routine, only the fast and flexible survive. Wise organizations devolve decision-making to the people who deliver value, sparking initiative and fostering innovation.

2. Design
If there is one thing we know, it’s that the consumer experience matters. Savvy organizations focus on the whole product and care deeply about the consumer experience. They balance empathy with data to deliver the WOW factor.

3. Learning
It is difficult for companies to innovate at the pace and scale of the market. Learning organizations run lots of experiments and keep what works. They leverage disciplined speed, system-level feedback, and validated learning.

4. Mastery
Great organizations set out to make a difference. They seek challenge rather than predictability. They foster effort over entitlement, mastery over success. They are disciplined, determined, and honest. And they keep on getting better.

Target Audience for workshop:
Managers, team leads, product owners, product managers, coaches – anyone who would like to rethink how to create winning products.

Some past talks by Mary:
2011 Agile and Beyond Conference – Opening Keynote – Mary Poppendieck
Competing on the basis of speed

Please do remember seats for this workshop are limited so book soon to avoid disappointment. http://booking.agilefaqs.com

Recently I facilitated a workshop at the Agile Goa 2012 Conference titled – “Agile Way of Dealing with Uncertainty in a Complex Adaptive World“.

Abstract: It is human nature to look for patterns while solving new problems. We have a dangerous tendency to reuse what we already know to solve the next problem. We rarely discard what we’ve learned; we simply build on top of it. Sometimes this is a useful tactic, but often new problems and their context are slightly (if not vastly) different than the previous ones. And applying our previous way of doing things, will not be best suited for tackling the new problem.

In the software world, we’ve seen a similar desire to find the “one true way”, “the BEST method”, “the silver bullet” to solve all software development problems. Alas, after decades of trying we’ve not found one.

In this workshop, I’ll let you discover why this is not possible and possibly explain how best to deal with this problem. This ideas in this workshop are based on my experience backed by latest research from Cognitive Science, Complex Adaptive System’s Theory and Evolutionary Psychology.

Slides:

Identifying the right pilot project is an extremely important first step towards your Agile transformation journey.

While selecting a pilot project, I generally look for the following characteristics:

• Importance: We don’t want to start with a project, which could shut down your business if things went wild. Nor do we want to pick a small pet project. Even if we proved Agile works well, it won’t appeal to the organization as it won’t be representative nor credible. A critical project with high-enough stakes is ideal.
• Dependencies: Fairly self-contained projects with minimum external dependencies are relatively easier for introducing change. If the team does not have the necessary skill or authority to take decision or if most of the project’s attributes are outside the organization’s control, it would be a very difficult pilot project.
• Stakeholder Engagement: Access to all the stakeholders is critical. Their involvement and buy-in is extremely important to make any sustainable change.
• Top-Management Support: During the transition, the team will run into many roadblocks and challenges. Having a good management support and backing will motivate the team to creatively solve those problems.
• Duration: To effectively capitalize on the learning and excitement, it’s important for the pilot project to be between 4-9 months.
• Size: A single collocated team with less than 10 members is an ideal size to coach. Gradually we can grow this team to large multi-site geographically distributed team/s.
• Stage: If the project was already in a fire-fighting mode, the team members would be under too much pressure to try anything different. If it’s a laid-back large maintenance project, team members might not have the motivation to change large legacy system. Project in its early stages with most of its team members on-board, seems to be a good stage to introduce Agile and Lean thinking.
• Team Composition: Most successful organizations have strong (vocal) leaders or connectors at the grass-root level. If we can influence these folks early on, they can be our internal change-agents. Hence while picking a pilot project, we consider their density in the pilot team.

Identifying a project with all these characteristics would be ideal, but is rarely the case. A good coach knows how to make reasonable trade-offs.

In today’s complex and dynamic environment, where companies are mercilessly eliminating waste and optimizing their processes to lower costs and improve operational efficiency, the term “slack” conjures up a host of negative perceptions.

Time and again, we run into companies that focus way too much on capacity utilization and ignore turn-around time and throughput. I’ve worked for companies who would hire more people, so work can be parallelized and done faster. But when that does not happen, they create work to keep everyone busy. Work expands to fill the available time and to keep everyone perpetually occupied.

Over and over again, we see companies batching work into large chunks, introducing all kinds of specialization, fancy workflows, layers of indirection and integrations in the name of better efficiencies. They might get better output, but are they achieving better outcomes?

Efficiency is the enemy of Effectiveness – Tom DeMarco, Slack

Let me share a story about Slack:

Yesterday I was invited to share my experience on “Enterprise Agile Adoption” to the entire Sr. Management @ big fortune 500 company.

During my talk, I describe my job at a company, which adopted Agile across the board. I said:

My job was to do nothing! I was not leading any team. The founder of the company (who hired me) did not set any targets or goals for me to chase. Basically I was there to do nothing.

People in the room, started laughing accusing the founder to be stupid and naive.

Don’t jump the gun yet. I discovered something magical.

Since I was not running around like a headless chicken, more people would stop by to have an informal chat. Like the one you have at a water-cooler or a coffee machine (think of serendipity & its implications on creativity for knowledge workers.) Many times we would end up in a spontaneous discussion/debate, shaping each other’s perspectives. Some times people would come to me with a specific questions/issues. Some times they would ask me to lend an ear for their rants. At times, when they were completely swamped, they would ask me to roll-up my sleeves and help.

Because I was not as smart as most of those guys, I would simply connect them with someone else in the company who could help.  We also did a lot of random events to ignite their thirst for learning.

All of this led to a great bonding with the teams. In some sense, I was playing the role of a connector. I won their trust. And soon, in a couple of months, I was the go-to person (at least start-with person) in the company.

Team members would compliment me saying:

Many deep-routed, hard organizational problems are being silently solved without anyone making a bid deal about it.

Which I thought was profound. And frankly I never felt this kind of satisfaction or sense of accomplishment before. This was by far, one of the best Agile transformations I’ve experienced.

Let’s step back and see what was going on there?

By bringing me in and not assigning me to any specific tasks, the founder introduced Slack into the organization. (I don’t think it was all planned, but the end result far exceeded our expectations.)

I experienced both kinds of slack:

• Time Slack – Since I didn’t commit to a task list nor was I being measure on how occupied I was (busy-ness metrics), I had a lot of flexibility. I had extra cycles, over and above the time required to finish the current work at hand. Which allowed me to be creative, experiment with new ideas, learn new stuff, adapt to changing priorities and be available to help anyone at a very short notice. Sounds like your grandmother’s advice “Work smarter not harder!”
• Control Slack – I wasn’t running to the founder for every little thing. I could take many decisions on my own. I even had a flexi-budget to invest/spend on things. In general, the company’s culture was very flat. Employees would make a lot of on-field decision. The company had a very decentralized decision making approach which lead to quick turn-around on issues. People were free to choose which projects to work on. It was perfectly fine to make some mistakes while learning new skills or attempting new projects. They massively leveraged the knowledge of people on ground to make well informed decisions. Even if the decisions were wrong, it took a small amount of time to fix them. Things would just happen at this company.

Exciting right? Slack sounds like common-sense right?

But for many years, there has been an ongoing debate among organizational researchers on the role slack plays in organizational adaptation (Bourgeois, 1981). Some argue that slack provides resources for innovation and change, thereby enhancing a firm’s ability to adapt to environmental shifts and improve long-term performance (Cyert & March 1963; Carter 1971; Mohr, 1969). Others argue that slack is an analog for inefficiency – a buffer which shields the firm and, in some cases, blinds it from changes which are needed to meet external demands (Litschert & Bonham, 1978; Thompson, 1967; Yasai-Ardekani, 1986; Williamson, 1963; Liebenstein, 1969; Migué and Belanger, 1974).

Nohria & Gulati (1997) took an intermediate position and argued that there may be an optimal amount of organizational slack because limited slack inhibits innovation by discouraging any experimentation whose success is uncertain while an abundance of slack also may inhibits slack by fostering complacency and lax controls.

Based on my experience with organizations, which rely on knowledge workers, I tend to agree with Nohria and Gulati. You can think of slack like a rubber band. A rubber band works best when it’s tight but not too much tension, and it doesn’t work at all when there’s absolutely no tension.

For example, 3M is legendary for providing it’s scientists with semi-structured time to work on their own projects of interest.

Google encourages its engineers to spend 20% of their time on projects that interest them, and the VP of Search Products and User Experience found that 50% of new product launches originated from the 20% time. Notable products from time off include Gmail and Google News.

I would strongly recommend reading Tom DeMarco’s book- Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.

In his book, Tom DeMarco compares slack to an open space in an 8-tile puzzle.

Organizations without the slack, are like a 9-tile puzzle with no open space. The result is highly efficient, but change becomes impossible: People are just too busy with operational work to think about the future.

eXtreme Programming has a practice called Sustainable pace. But unfortunately this practice is often forgotten or companies struggle to put it in practice. The idea is that productivity does not increase with hours worked. Tired programmers are less productive than well-rested ones.

Tom suggests that businesses that build in sensible amounts of time and control slack enjoy four specific competitive advantages:

1. Better responsiveness.
2. Enhanced flexibility.
3. Greater retention of key people.
4. An enhanced capacity to invest in itself

At the Agile India 2010 conference, Sandeep and I ran a workshop to shed some light on the kind of aping that’s taking place in the software companies trying to be Agile.

Clearly we don’t have all the answers. Nor do we know the best way to build software in the right way (if there was one.) But we do know one thing:

The right way doesn’t involve mindlessly following practices just because some “expert” says you need to.

In this workshop we took a critical look at various “agile” practices and tried to highlight the dogma and ceremony that has creeped in. We also questioned if the practices defined a decade ago are still applicable? If yes, have they evolved since? What are some of the original creators of these processes practicing today?

How has Agile evolved over the last 12 years?

This is an introductory presentation on the essence of Being Agile vs. Following Agile. And why being Agile is important? I’ve also tried to show an evolution of Agile methods over the last 11 years and the future of Agile. Also take a sneak preview into what challenges an organizations may face when trying to be agile?

How do you measure or know the effectiveness of a Scrum Master?

IMHO on a given team, in less than 6 months, an effective Scrum Master will make:

• themselves redundant
• process second-nature for the team

That would be the true test for their effectiveness.

In the mean time, I would look for:

• Apart from effectively facilitating (not enforcing) the Scrum ceremonies, is the SM helping the team understand the rationale behind those ceremonies?
• Is the SM creating a culture of safe-fail experimentation where the team can experiment, learn and grow beyond the standard Scrum ceremonies? If the team is not evolving their practices and work culture, is the SM really doing their job?
• Does the SM encourage System’s Thinking and uses techniques like Value Stream Maps, Five Whys, A3, etc. to identify & highlighting bottlenecks in the team?
• Has the SM been successful at creating Self-Organized Empowered Team? Or is the team waiting for directions from the SM?
• Is the SM able to emerge as a leaders and be the voice of the team, shielding the team from external interferences, yet creating a healthy collaborative culture?
• Is the SM able to motivate the team and steer them towards excellence?
• Is the SM recording and surfacing important and relevant data about the team’s performance to the team? Basically feeding the team, food for improvement.
• Is the SM proactive (instead of reactive) about resolving issues?
• Is the SM approachable? Believes in servant-leadership? Extremely knowledgeable about processes? Keen learner and open-minded?

Good Product Owners are:

• Visionary
• Can come up with a product vision which motivates, inspires and drives the team
• Aligns the product vision with company’s vision or mission
• Passionate Problem Solver
• Should have a knack of identifying real problems and ability to visualize a simple solution to those problems.
• Has good analytical & problem solving skills
• Subject Matter Expert
• Understands the domain well enough to envision a product to solve crux of the problem
• Able to answer questions regarding the domain for those creating the product
• End User Advocate
• Empathetic to end-users problems and needs
• Able to describe the product from an end-user’s perspective. Requires a deep understanding of users and use
• Is passionate about great user experience
• Customer Advocate
• Understands the needs of the business buying the product
• Ability to select a mix of features valuable to various different customers
• Business Advocate
• Can identify the business value and synthesize the business strategy as measurable product goals
• Has a good grasp of various business/revenue models and pricing strategies
• Capable of segmenting the market, sizing it and positioning a product (articulate the Unique Selling Proposition)
• Is good at competitive analysis and competitor profiling
• Able to create a product launch strategy
• Communicator
• Capable of communicating vision and intent – deferring detailed feature and design decisions to be made just in time
• Decision Maker
• Given a variety of conflicting goals and opinions, be the final decision maker for hard product decisions
• Designer
• Possess a deep understanding of (product) design thinking
• Able to work effectively with an evolving product design
• Planner
• Given the vision, should be able to work with the team to break it down into an iterative and incremental product plan
• Capable of creating a release roadmap with meaningful release goals
• Is feedback driven .i.e. very keen to inspect and adapt based on feedback
• Collaborator
• Able to work collaboratively with different roles to fulfill the product vision. Be inclusive and empathetic to the difficulties faced by the members of the cross-functional team
• Given all the different stakeholders should be able to balance their needs and priorities
• Empowers the team and encourages everyone to try new ideas and innovate

Disclaimer: This list is based on my personal experience but originally inspired by discussions with Jeff Patton.

In my experience its hard (not impossible) to find someone who possess all these skills. It requires years of hands-on experience.

Some companies form a Product Ownership team, comprising of different people, who can collectively bring these skills to the table. Personally I prefer supporting one person to gradually build these skills.

I amazed how easily companies get convinced that they can send their employees to a 2-day class on Product Ownership and acquire all these skills to be a certified Product Owner.

Often companies undervalue the part-time coaching model.

What do I mean by part-time coaching model?
A coach is onsite, working hands-on with the team for a week and then offsite (accessible via email & phone, but off the project) for a week. Basically, the coach is available on-off either alternative weeks or a some other timeframe.

Personally I’ve experience the following advantages of a part-time coaching model:

From the company & its employees’ point of view:

• When I’m not there full time, teams realize they cannot fully depend on me. I’m not the bottleneck for making decisions. The teams start to take ownership and make more decisions on their own (usually by consulting me, but not waiting on me.)
• When I steps out for sometime and come back to the team, I bring a slightly fresh perspective and can pay attention to weak signals. Many times we get so engrossed in what we are doing, that we might miss out paying attention to something else.
• Coaching can be intense. Having a little time off from coaching helps the teams get a breather. Which makes the overall coaching more sustainable.
• As coaches we expect things to change much faster rate than usually they do. If we are there full-time, it might start to bother us. But with the on-off model, the slower rate of change seems more acceptable. Similarly the team does not feel pressurized to accept change at a rate that might not be sustainable or acceptable to them.
• The management seems to get more confidence in the whole engagement, because they can see things are not blowing up when the coach is not around.
• Last but not the least, it does have a good financial incentive for the company.

From the coach’s point of view:

• Having some downtime is good for the coach to build/upgrade their skills.
• Can help achieve a better work-life balance.
• From a risk management point of view, it allows a coach to take on multiple part-time client.

Hopefully, all of this leads to a more effective coaching engagement.