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.
After pursuing a highly satisfying and successful career for 23+ years in a corporate job, I decided to ditch the cubicle in Oct 2014, and take the unknown and uncertain path of entrepreneurship. Unlike conventional entrepreneurship, I decided to pursue, or rather chart my own course as a knowledgepreneur in the newly emerging gig economy.
While many people pursue this path for several reasons, I chose this path in the following manner:
These broad-level time-buckets have helped me to find the purpose and stay true to it. This arrangement has also been very helpful in building my professional credibility and capability as a coach and mentor, and to explore newer ideas to help my clients. As a result, while I pursue my purpose and passion, happiness has chosen to pursue me (rather than me chasing the happiness!).
It's been 18 months since I started with this experiment, and it has been extremely successful, as I have not only managed to meet my original goals, I have also been successful in building a commercially viable and sustainable business model.
In this talk, I will take the audience through my journey :)
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:
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.
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?
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,
Five years ago, Kiran Jonnalagadda and I started to build HasGeek with the belief that there is need for conversations and communities around more and more focussed technology topics. We were clear that we wanted build technology communities and drill focus in every conference we'd launch under the HasGeek banner.
We were also determined to build the conferences and business in line with the following principles:
Five years down and we have been agile and slow in various aspects of organizing conferences and building our business.
In this talk, we will share what it takes to build a startup in an agile and expedient manner around assets such as goodwill, trust and networks. Goodwill, trust and networks are critical for any startup's success. The key takeaway for the audience is to identify their strategies and practices for building these assets and build a business or community or both in an agile manner.
Scrum, XP, Kanban and related methods have been proven to provide step changes in productivity and quality for software teams. However, these methods do not have the native constructs necessary to scale to the enterprise. What the industry desperately needs is a solution that moves from a set of simplistic, disparate, development-centric methods, to a scalable, unified approach that addresses the complex constructs and additional stakeholders in the organization—and enables realization of enterprise-class product or service initiatives via aligned and cooperative solution development.
"Release Early, Release Often" is a proven mantra and many companies have taken this one step further by releasing products to real users with every commit a.k.a Continuous Deployment (CD).
Over the years, I've built many web/infrastructure products, where we've effectively practiced CD. However at Edventure Labs, when we started building iPad games, we realized there was no easy was to practice CD, esp. given the fact that Apple review takes a few days.
Our main question was: As mobile app developers, how should we architect/design our apps for CD?
We were a young startup, learning new behavior about our users (kids aged 5-8) everyday. We could not afford any delay in releasing latest, greatest features to our users. To solve this problem, I believe we've built an innovative solution to enable any mobile app developer to achieve CD.
If you are building real products, which have platform/3rd-party dependencies and you want to practice CD, this session is for you.
As more and more organizations are transitioning to Agile, there still exist a lack of understanding on how testing fits in the Agile teams. Is it just about placing a tester in every team? How can we realign the team members including testers from being on silos to an effective cross-functional team? Pradeepa Narayanaswamy shares her insight on the key basics of Agile testing along with understanding the Agile testing mindset and testing goals. Pradeepa also shares her ideas on how to manage defects, what to measure as metrics and what to document. Learn what you need to know as a tester who are new to Agile. If you are an experienced Agile tester, review these important basics and realign the concepts that may have been overlooked or forgotten in your teams.
Agile promotes empiricism and change, yet many practitioners continue to scope out and estimate delivery times and costs for software products and projects.
Defenders of the art of estimation claim that we need to estimate software projects in order to answer common business and customer questions such as:
This session challenges participants to flip these questions on their heads and seek alternatives to estimation rituals. It covers the many risks inherent with an estimation culture and demonstrates real, practical alternatives, both at the portfolio and the sprint level.
Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?
Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.
During this workshop, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.
This 90 mins workshop teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.
This is a sample proposal to demonstrate how your proposal can look on this submission system.