Coming Soon!

Scrum's underlying philosophy is similar to the idea of "aggregation of small gains" over a reasonable period of time eventually leading to breakthrough results. In this talk, we will review examples from diverse fields such as military and sports and then discuss how these ideas help improve the efficacy of Scrum implementations to accelerate innovation.

In recent years, two similar-sounding but distinct approaches to product discovery have emerged: Design Thinking and Lean Startup. Most of the literature and experience reports refer to one of them, with similar frequency, without really giving much guidance on when to use which one of these approaches. This creates a confusion whether one is using the right approach. While a method must not be used for the sake of using a method, it is important to understand why, if at all, a given approach is likely to be more effective in a given context.

In this talk, I will compare and contrast these two approaches and address the following key questions:

1. Why do we have two (or more) approaches to product discovery?
2. What, if any, are the fundamental differences between these two approaches? 
3. How can I decide which approach is likely to work better in a given situation?

The talk will focus on contemporary literature, expert guidance, industry data points, and author's own experiences, and will provide action guidance for the practitioners to apply in their daily work. 

Enterprise Agile Transformation initiatives are BIG. Change at this scale of thousands is tough. 

The Leaders and Executives involved in these initiatives are going through their own personal transformation. Change at this scale of one is equally tough. 

Since our last session at Agile India 2016, (March 2016), we have worked with several hundred more leaders, put on two gatherings for leadership story telling, published two books etc.. You'll hear a lot of new stories direct from the field, with those experiencing the transformation firsthand.  

Siraj Sirajuddin (SPCT4) has worked with hundreds of executives leading enterprise agile transformation initiatives. These are their stories of personal growth and individuation. We will hear how transformation at a personal level is the leverage for transformation at a collective level. We will also learn of unique methods that activate personal transformation for leaders who are ready to step into their leader persona but are unable to get that from traditional leadership training and coaching methods.

In May 2015, I got involved in coaching a products organization in improving their agile practices. This was a unique coaching experience for me because of some interesting experiments that I did:

• I focused on coaching and literally zero consulting. 
• My coaching stance was only limited to showing them the way, initially training them on the essence of agility, and later on to simply shine light on areas that needed their attention, and if needed, share ideas from the industry.
• I spent just 1day every month with the teams to only focus on my coaching sessions, and a few hours during that time to review the progress.
• The teams and the leadership would decide on what they wanted to do, and how much they wanted to change.

In ~6 months that I coached them, I found that the team has matured to a very high level of self-organization. They changed their process, their key roles and responsibilities, and self-organized into a very high-performing teams (which was corroborated not just from the high-energy levels of their teams but also the project metrics).

I call this model Minimum Viable Coaching, and it was helpful in demonstrating how a coaching could be made extremely effective if there is a client who is willing to trust its team in their ability to self-change, with minimal guidance (more of direction than really support) from an external coach. It also requires a coach to think in terms of minimum self-interests (read commercial interests) but focus on what will make the client successful in the long run.

In this experience report, I will share my approach and experiences, and offer some ideas on how the coaching can be elevated to a true coaching where the enterprise becomes self-organizing on their own.

Most new products and startups fail. The don't fail because the idea is fundamentally bad, or their talent isn't good enough, or they don't have enough funds or resources, but because of essentially prematurely scaling - i.e., without validating the hypothesis adequately, building a cost structure that is not sustainable over long run.

Customer Development model is the systematic way to discover and validate customers and build a company. Applying the principles of Lean Startups, one can go about validating the business model canvas before running out of money. However, when it comes to value proposition design, there is often a serious misalignment between what customers really want and how we create value for them.

In this workshop, we will learn how to use Value Proposition Canvas to sketch out and understand those relations better, and make more intelligent hypotheses, that hopefully lead to more successful products and services.

An intro to design thinking ideas...

In agile teams, three critical aspects of how individuals and interactions shape up are:

1. Individual role / title

2. Group / peer pressure

3. Self Organization

In this session, we shall simply play games to highlight the dysfunctions caused by traditional team structures, and facilitate the attendees into 'discovering' how agile practices help mitigate them

In my previous organization, I had the charter to implement "End to End Execution Framework". The goals behind this company-wide cross-functional strategic program were to:

- align product development with sales, delivery and operations

- orchestrate support functions such as legal and finance with product creation and selling processes

- provide visibility into process flows to ensure bottlenecks could be eliminted fast, and

- establish cycle times and provide dashboards and analytics to help improve overall lead times

In Dec 2013, we embarked on an ambitious companywide program to map process flows from pretty much all the functions: Pre-sales, Sales, Marketing, Legal, Finance, Service Delivery (SD), SD PMO, ED Engineering, Design Studio, Product Management, Product Engineering, IT, Production Ops, Analytics and finally Optimization. In the first phase, we mapped and optimized 50+ process flows that were grouped under three major value-creation heads - build product, sell solution and deliver outcomes. In several cases, the processes were not documented, and in some cases, the processes didn't exist. The activity took close to 4+ months of dedicated team of 3 process experts.

In next phase, we custom-built a workflow solution to help streamline end-to-end process flow. It was application of Lean thinking into the overall execution framework with the goal to imrpove agility through the entire value stream. We implemented workflows that allowed us to build process flows, provide visibility, management dashboard and metrics.

In this session, I will share our journey, pains and accomplishments.

This is a continuation of my work that was proposed in Agile India 2014. (http://confengine.com/agile-india-2014/proposal/26/agility-the-scale-of-busine). Based on this work, I will also propose a framework for addressing enterprisewide agility.

In 2003, we had a major problem to solve - our products had far too many open field defects, and the bug arrival rate was moe than the closure rate. We tried to fix using our process which involved shipping quarterly service packs, but that was not only elongating the lead time, it was also not very amenable to changes. The process for customer specials (specific features, etc.) was not any better, and invariably it led to exec-level escalations just to get some deal-blocking customer escalations into the service packs mid-way in the quarter.

In 2004-05, we experimented with a pull system that limited the work in progress and created a more smoother flow of value. The result of this system was that we were able to significantly reduce the defect backlog, and were able to bring down cadence of features and bugs to a weekly cadence. The experiment was so successful that in about 6 quarters, we had fixed most of the field defects (brought down individual product's defect backlog to single digit) and we had to disband the team as there was no work left for them!

We were inspired by Tom Gilb's "Evo" method and experimented with it to create a weekly cadence. However, we found that the nature of field defects and customer specials was stochastic in nature and didn't lend itself very well to a timeboxed framework like scrum. However, there were no off-the-shelf methods available back then that were a viable alternative. Hence, we experimented with various methods and blended-in elements form various methods to create out our very first kanban by limiting work in progress.

In this talk, I will explain our first kanban experiment, and also compare and contrast with the later-day Lean Kanban by David Anderson.

Feedback is perhaps the most important aspect of the overall agile lifecycle. If the feedback is too wide and shallow, it won't give enough actionable feedback. If it is too narrow and deep, it might fail to register feedback outside its focus area. So, how does one go about designing feedbacks that enable agile learning. We call them agile feedbacks.

In this brief session, we will share an experience from designing agile feedbacks for agile trainings and workshops. The objective was to get most critical feedback in shortest amount of time to enable quick action planning. We created feedback that took a maximum of 5 minutes and enabled the most important learning in both, focussed as well as open-ended manner that allowed us to focus on the most critical items. We employed elements of Design Thinking and Rapid Iterative Testing and Evaluation (RITE) to improve the process and quality of feedback themselves. We will also be touching up these concepts and how effective they were.

Pesentation deck is now available at http://www.slideshare.net/Managewell/what-next-31791295

Modern management methods are still based on the then seminal work by Henri Fayol some 200 years back, followed by Frederick Taylor's work some 100 years back! Sadly, those models were predominantly based on industrial work, and don't really work that well in knowledge industry and today's sociological dynamics at workplace. Classical Agile methods codify several people practices that allow for a self-organizing team to evolve, but doesn't offer a lot of guidance on how to develop and groom leadership for agile organizations beyond a software team. Management 3.0 takes this issue further and develops it into a separate discipline altogether. On similar lines, Holacracy seeks to create social technology for purposeful organizations, though not specially targeting software organizations. So, the issue of leadership still continues to be unresolved and rather left to pave its way on its own. Unfortunately, when we want to achieve true end-to-end agility, it is not enough for software teams to be charging at top speeds but leadership not evenly matched to support them well in their endeavors. We clearly have a problem at hand...

In this talk, we will study how the role of leadership has evolved and what does it look like for agile organizations at present. Many agile methods take an extreme view that limit leadership to team-level collective ownership of leadership. However, that might not be enough because of various reasons. In any non-trivial organization, whether a software organizations or any modern business employing software for business advantage, the reality is that organization units beyond a plain-vanilla software teams do exist. So, how does one go about grooming their top talent for playing an effective part in this process?

Finally, we will also try to take a shot at some of evolving paradigms. For example, all these management thoughts are still based on the kind of outdated premise that an organization is based on 'boundaries' of operations. However, already we see that model being broken down, and the future teams look more like boundaryless entities bound with nothing but a unifying purpose that brings a bunch of volunteers together for a period of time. If our success increasing depends on such teams being able to effectively self-manage themselves, what role does leadership have to play in it, and are we getting ready for it? 

[24]7 Customer, Inc started out in customer service space from Bangalore in 2000. Today, it is a sucessful mid-size company in voice-based customer support that also creates IP and products in big data and predictive analytics for some of the biggest names in business, and is a a high-growth company headquartered out of US. The growth in product R&D happened both organically as well as from acquisitions across multiple geos. While the initial / startup stage processes had been extremely successful in building the company's strong foundation, it was felt that the next stage of growth might not be a linear extrapolation of the past successes. Recognizing this futuristic need, it initially embraced agile software development methods in Q1 of 2013 to improve responsiveness, predictability and time to market in the product development organization. In Q2 of 2013, it embarked upon an ambitious company-wide program. The charter was to establish an end-to-end execution framework to make the entire operations efficient and effective - right from marketing and pre-sales to delivery, deployment, operations and ongoing optimization. 

In this session,

• We will analyze challanges involved in scaling-up agile adoption outside the software team across the entire organization.
• Specifically, we will also discuss how we addressed some of those unique challanges that are associated with growth and scale, and
• What does it take to achieve true end-to-end agility.