Yuval Yeret Interview

Yuval Yeret is a senior enterprise Agile Coach at AgileSparks. He has substantial experience in coaching and leading the teams through Agile ways-of-working. He has led many long term strategic initiatives and one of the leading Kanban practitioners on the enterprise product development world.

He published ‘Holy land of Kanban’ and is the recipient of the Brickell Key Award for Lean Kanban community excellence. His experience in leadership/management along with his experience in  networking, security, storage in both Dev and Ops of IT/Product development gives him an edge in DevOps trend.

Yuval Yeret

Here is an excerpt from the conversations we had with him.

1. You received the Brickell Key Award for Lean Kanban community excellence, driving Kanban adoption in Israel. Tell us a bit about your experience popularising Kanban in Israel.

Well, It has certainly been an interesting journey so far. It is hard to popularise a disruptive innovation like Kanban under a strong incumbent like Scrum. I found that the best way to get traction for the ideas behind kanban was to focus on what job it could do better than scrum for people. Turns out Kanban is quite good at doing the job of educating leadership about Lean/Flow since its language is more explicitly connected to the Lean/Flow concepts. It is also quite good at helping organizations who like to “build their own agile” rather than following a methodology religiously. It is also a great “gateway drug” method to get you going towards a lean/agile way of doing things. The visibility and mindset you use catalyzes the right kinds of behaviors and structures. I’ve seen several cases of teams starting with Kanban on top of their waterfallish structures and processes and starting to use more agile structures and processes like Feature teams, User Stories, ATDD, CI as they learned about the potential value these changes might provide when considered through a flow perspective

2. You claim that Kanban is a match made in heaven with DevOps. Tell us why?

DevOps talks about System Thinking, End to End Flow, Closing and amplifying feedback loops. All of those can be done with an iterative approach but in most real-world scenarios are a bit hard to fit into a sprint and are better managed as a flow using something like a Kanban pull-system. At the other end, the highly mature teams with Continuous Delivery capabilities balk at the “slowness/inflexibility” of the scrum iteration and prefer a fast-flow kanban system. In addition, DevOps is typically a journey for most organizations. The most popular description of that journey is found in “The Pheonix Project” by Gene Kim (which is highly recommended btw). And that journey’s steps – System Thinking, Amplify Feedback Loops, Continuously Experiment towards improvement map very well to Kanban’s principles of starting with where you are with respect to how things are done and by who as well as the practices of Visualization, Flow Management, Different levels of feedback loops

3. What is the biggest challenge in implementing Kanban on DevOps?

I would say the biggest challenge is having the discipline and resolve to get to an end to end visualization of the workflow (especially if this is only in your sphere of influence, not your sphere of control) not to mention move to Pull mode and WIP limits. You step into dangerous territory when you convey messages like “we will not pull this, we’ve reached our WIP limit”.

Another challenge that is even more extreme in DevOps compared to typical Agile situations is the need for end to end leadership looking at the performance of the entire value stream. (Agile only needs to bridge the Product/Dev/Test)

4. DevOps and Continuous Delivery is becoming pretty mainstream. At companies where these approaches are used, what metrics are they capturing to prove the ROI?

I wouldn’t necessarily say DevOps and/or Continuous Delivery is mainstream. I think there is a big chasm to cross. The Innovators who were typically web companies like NetFlix, Flickr, Etsy, Flickr, Amazon, Google. Then came early adopter companies which ranged from other web companies to companies with adventurous IT organizations with a real need to innovate faster in order to compete and/or a real sustainability crisis to deal with. Based on these problems/reasons for DevOps the typical metrics are deployment frequency, lead time for changes, and mean time to recover from failure.

Early adopters by their nature are less interested in metrics and ROI since they went into DevOps with an urgent business problem to solve. So initially data wasn’t readily available. But as DevOps is trying to cross this chasm it indeed needs to make a stronger business case as the mainstream market typically looks for this kind of proof as well as the validation that DevOps indeed works for a similar context to the one they are in. People like Gene Kim and some others in the DevOps community realized this some time ago and started issuing “State of DevOps” reports yearly. The 2014 report goes beyond reporting on the benefits for these operational metrics and is able to show a correlation between these leaner operational metrics and better IT performance overall as well as even better business results.

5. What is your favorite DevOps principles? Anything that changed the way you view software development?

I’m a Kanban guy. So I like Systems Thinking and Visualization of the end to end flow. Every time I help a group look end to end and see the light bulbs turn on just by seeing the initial kanban board view of their current situation it is a very satisfying moment. Asking them to play “what if” and simulate the future or a past scenario makes it even more realistic and drives the understanding of the lean/DevOps principles even deeper. I also like to help people understand the cost of the delayed feedback in the way they are currently doing things and use it to reduce the batch sizes in their processes and justify investment in various practices and even structural changes. This combines the “Amplify Feedback Loops” principle together with Don Reinertsen’s Cost of Delay/Flow principles.

6. What are some of the common problems, while applying DevOps concepts to Enterprise IT/ Product Development as compared to hosted-web apps?

Well the toughest problem is that Continuous Delivery is much harder and sometimes even an unrealistic goal. This makes it harder to close the feedback loop. It also makes it harder to justify tighter internal loops as people will tell you “why bother”. The way I deal with that is emphasize the cost of delayed feedback not just the cost of delayed time to market. I also insist the organization try to find creative ways to close the feedback loop like a cloud-based lab, early access programs, etc. I also emphasize that DevOps!=CD. You can benefit a lot from the DevOps thinking, principles and practices without going all the way to CD. I find Reinertsen’s principles of flow very useful in this context.

7. Is there any special advice you would provide to people applying WIP limits to DevOps projects?

Especially when talking about enterprise DevOps your end to end flow will probably NOT be at the user story level. It will probably more at the “MMF”/Feature”/”Epic” level, whatever you want to call that unit beyond the story that DOES make some sense at the business level to deploy and enable for users. In these cases people should make sure that their WIP limits and their flow visualization in general apply at this level. In fact, in several enterprise DevOps cases we started from agile teams using some process like Scrum/Kanban/Scrumban and DevOps was one of the triggers for starting to actively manage the end to end flow of Epics/Features. To learn more, come to my workshop at Agile India 2015 conference.


This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2015#workshops

Mark Lines Interview

Mark Lines along with Scott Ambler, co-created the Disciplined Agile Delivery (DAD) which is a process decision framework designed to help organizations apply agile and lean for their unique contexts.  It provides guidance for “disciplined” application of agile across the enterprise.

Mark Lines

He show teams how to extend Scrum with other supplementary practices from a variety of methods such as Extreme programming, Kanban, Agile Modelling and the Unified Agile Process. He help teams apply DAD with its hybrid approach that is suitable to the unique needs of the organization. Mark has over twenty five years of experience in delivering software solutions.

Mark co-authored “Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise”. Also co-founded the Disciplined Agile Consortium, the certification body for Disciplined Agile.

Disciplined Agile Delivery

Here is an excerpt from the conversations we had with him.

1. What are the challenges in implementing Scrum for large complex projects?

Software development is hard.  Scrum is described by a 16 page guide.  Clearly that is not enough guidance to deliver enterprise, mission critical applications.  So in the past it has been left up to the practitioner to try and supplement Scrum with ideas from other methods such as Extreme Programming, Lean, Kanban, and others.  But even if one has the experience to piece together practices from these methods into something that makes sense, that is still only effective for individual, small project teams.  Once you are successful at the team level, scaling it across many teams, on projects of many different types can be very challenging.  Indeed, without a solid foundation that DAD provides it is very difficult to be successful applying agile across an organization.

2. How does DAD address the challenges highlighted above?

To address the challenges of being effective at the team level DAD is comprised of a hybrid of proven practices from the leading agile methods.  It provides a cohesive approach that addresses the complete lifecycle, not just the construction aspect that mainstream methods such as Scrum focus on.  Having applied the DAD framework properly, then we are ready to address scaling concerns such as distributed teams, compliance and regulatory situations, domain complexity, and large teams.

One of the flaws we see with other scaling approaches such as Large-Scale Scrum (LeSS) is that they rely on Scrum itself.  Although scaling based on Scrum makes sense in many cases DAD doesn’t prescribe Scrum.  In fact DAD has four different lifecycles which address other needs such as Lean, Exploratory (Lean startup) and Continuous Delivery.

One thing I would like to point out is that people often misinterpret DAD as being a scaling framework.  While it certainly is applicable for scaling, it is more often used for small and medium sized teams.  It is a “process decision framework”, providing guidance to customize your approach for the vast variety of contexts that organizations find themselves in.  One scaling framework will not be best in all situations.  Fortunately DAD is flexible.  We like to call it “pragmatic agile”.

To learn more, come to my workshop at Agile India 2015 conference.

3. Tell us a bit about what got you started with DAD?

That is an excellent question.  Both Scott and I have been using agile techniques long before the agile manifesto was written.  We had different names for things but we have been build software iteratively and incrementally for many years prior to 2001.  While Scott was at IBM he consolidated his own past work as well as harvested proven techniques from other methods into DAD.  It was during that time that we agreed to write a book on the framework.  Contrary to what many believe however, DAD is not IBM’s.  The Disciplined Agile Consortium is responsible for maintaining and evolving DAD.


4. Based on your experience coaching teams, how do they react to the hybrid approach suggested by DAD?

Without reservation I can tell you that teams that take time to understand what DAD really is and are very happy with DAD.  It bridges the gap between what project teams need to be effective with agile and lean and what the enterprises need for effective cross-team and program collaboration.

5. What is your take on certifications? How do they help the practitioners?

Scott and I have openly criticized agile certification schemes in the past so some people were surprised that we developed a certification program for DAD.  We decided that certification can be a valuable thing but the program needs to be credible.  As such, we have a multi-level Belt program that shows the progress of knowledge, experience, through to community involvement.  Lower level belts demonstrate experience on DAD projects while higher belts reflect coaching and organizational DAD transformations experience.

Regarding how certifications help practitioners, we have found that some organizations want to hire people that have demonstrated a commitment to learning what DAD is all about, and sometimes they want evidence that they have actually applied the DAD principles on projects.  In this regard it becomes a valuable thing for an agile practitioner to have on their CV.

Although not required, attending a DAD workshop is an excellent way to prepare for the Yellow Belt certification test.  Additionally, most DAD workshops include a free certification test.  More information on the certification program can be found at www.DisciplinedAgileConsortium.org

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2015#workshops

Fred George Interview

Fred George is a developer and co-founder of Outspace system. He is a principle consultant at Fred George Consulting. Fred coined the term microservices. He coaches teams in Advance Agile concepts and in microservice architecture. Fred is one of the early adopters of Agile and OO. He has used over 70 programming languages and have worked across the globe. He started ThoughtWorks University in Bangalore, India, based on a training program he developed in the 90’s.

His specialities includes Software development; programmer anarchy; agile; lean; change agent; XP; software architecture; Ruby; Web HTML and CSS; Sinatra; Rails; 70+ languages

His contributions to the Agile community is remarkable and he continues to make an impact through his experience and domain expertise. 

Fred George

Here is an excerpt from the conversations we had with him.

1. What does it take to be an early adopter of any new language or technology?

Two thing: awareness and a bit of luck. First of all, you need to be aware of what new stuff is coming. There are an awful lot of blogs and announcements every day, so I find this channel useless. I tend to use conferences to expose myself to the latest thinking. And with so many conferences producing videos, a survey of the conference program and a few minutes of video can give you hints of what new is coming. Lately, MicroServices (which just had a dedicated conference in Berlin) and Docker seem hot.

The second thing is a bit of luck: Is this new idea worthy of attention, or is it one of the thousands of ideas that is seriously flawed? Fortunately, you can make your own luck. Find a handful of respected names in the industry that seem to be on top of the latest things, and watch what they do. Martin Fowler, (Pragmatic) Dave Thomas, and Neil Ford are some of my favorite guys to watch. They each have excellent track records of moving to better languages and technology platforms.

2. What is your advice to a novice polyglot programmer?

By polyglot, we are talking about a programmer who knows several different languages. My advice is to keep learning them, and strive for diversity of styles. Ruby and Python are very close; better to learn Clojure or Elixir if you already know Ruby. You should be trying to pick up at least one new language a year.

Everyone has their own style of learning. I am “hands-on”; I need to write a real program in the new language to really understand it. I know others that read a book and come away skilled (that’s just not me). So know your learning style. For me, I take some standard exercises (or code kata’s), and implement it in a language I know and a new language. What seems hard? Go look that up online.

3. Out of the 70, do you have any favourites programming languages? Why?

I think I had two profound languages that changed my programming style. The first was PL/C, an internal IBM language similar to C. Before that I was using assembly language, and I didn’t trust a program to write code better than I could. I was wrong. The early compilers didn’t get register assignments confused. I converted.

The second profound language was Smalltalk, a true object-oriented language. I read the book in 1987. It made great sense. I then started to write code, and realized I had no idea where to start: complete brain freeze. It took most of the next five years to understand it, and another five before I was really more productive.

So the short answer is Smalltalk because of how it helped me decompose real problems. I currently favor Ruby which is very close to Smalltalk in programming style.

4. These days microservices has become a buzzword. Personally I heard about microservices from you first in 2011 time frame. Tell us a bit about what created the need for a microservice architecture?

I coined the term originally to describe the ridiculously tiny programs I was writing at a client in 2005-6. As I was learning service-oriented architectures, I constantly hounded my colleagues to help me understand the appropriate granularity of services. I finally tried making them as small as possible, but still do something (an OO design technique). The idea of microservices really took off when we used the technique at a London startup in 2008.

Microservices is a natural result of simply going faster, measured from requirement through delivery. It has been facilitated by widely available cloud computing, better languages and platforms (Ruby, Python, Node.js), and high bandwidth communication between services (there is a 50GB backplane on high-end server racks). I know of at least 3 places that have independently arrived at the same design (microservices) for the same reasons.

In London, we were deploying new code into production every 3-4 minutes. That also drove organizational changes.

5. What are the advantages of microservice architecture?

There are two real business benefits: The ability to try ideas out efficiently without large time and resource expenditures, and robustness of systems that can detect and restore failures so quickly. I strive to design systems that survive failures, something much easier with microservices.

There is also an organizational benefit: Happier developers. We want to write and deliver code, and being able to do that everyday is very satisfying. Most of us exposed to the rapid processes that support microservices would not go back to the old processes.

6. Many companies are finding it hard to decide how micro should a microservice be. What is your advice to them?

First, realize there is a lot of diverse opinions on what microservices are. There are variations in size (from a few dozen lines of code to a few thousand) and interaction design (chains of service invoked via RESTful interfaces, or loosely couples, bus-attached services). So we (as an industry) are still exploring the possibilities.

Regardless, some of the early steps are the same: Break the single, cohesive database fiction most enterprises hold dear. One recent successful CTO cited his first step as “killing the JOINs” as a means of breaking the database down.

There are several representative projects to model yourself after. Netflix (which tends toward larger services) has open source most of their infrastructure, and other major companies are picking that up with great success. On the smaller side, the rewrite of uSwitch (of London) is a great example, as is the recent rewrite of Wunderlist (of Berlin); both are talked about publicly.

I’m hoping that we can have a much deeper discussion on this during my workshop at Agile India 2015 Conference. Join us, if you are interested in being part of the discussion.

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2015#workshops

Diana Larsen Interview

Diana Larsen founder of FutureWorks Consulting has many years of experience working for products in Software Industry. Besides coaching the teams in Agile ways-of-working she also leads teams/projects based on collaborative thinking and planning. Her skills as a facilitator for open space sessions and retrospectives requires no introduction. Her ability to solve critical problems in tough situations has given her an edge in her work.

Diana Larsen

She has co-authored three books including ‘Agile Retrospectives: Making Good Teams Great’. Her work with James Shores on Agile FluencyTM model is quite a hit and its been applied across teams all over the world. She has served as a chair for Agile Alliance and have joined as a board member for Organisation Design Forum.

Agile Retrospectives

We had a short chat with her about her work and also about her workshop at the Agile India 2015 conference.

1. What is the biggest bottleneck for collaborative work culture?

In most organization that find a bottleneck (not all do), I’ve seen a bottleneck caused by shifting expectations. The change in expectations influences bottlenecks in information flows, communication channels, product decisions, opportunities to learn from experience, and many more aspects of software development and product delivery. Transitioning from a hierarchical way of working to a more collaborative work culture creates changes in role definitions and role requirements. It requires letting go of habitual behaviors that may have worked well in the hierarchy, but no longer serves anyone when collaboration becomes a critical part of the work process.

For example, a QA or Engineering manager may have been rewarded for managing a number of people in a narrow functional area, for getting information from direct reports and transmitting it to the manager’s boss, for following conventional wisdom for keeping costs low and productivity high. In short, for working well within their functional silo. Now we know that for knowledge work like software development, none of these activities deliver the desired result…though they did protect opportunities for promotion. As many have said, “what gets rewarded gets done” And no one was being rewarded for taking the kind of risks that lead to innovation or other breakthroughs in performance which thrive in a climate of collaboration.

Visionaries are designing organizations for collaboration. These firms remove the bottlenecks imposed by the strict hierarchies of the past.

2. What are the typical challenges you’ve seen with Agile implementation in large organisations?

The biggest challenge I see is the belief that an Agile implementation begins and ends with making changes in how front line delivery teams do their work. Another, more insidious, challenge is a fundamental misunderstanding of the nature of knowledge work and how it is best accomplished. This misunderstanding seems to expand with the size of the organization. I rarely encounter it in startups or small companies.

Knowledge work differs from other work by its emphasis on “non-routine” problem solving. Tim Ottinger and I have shared conversations about whether software development is more about the ability to learn quickly or make high quality decisions quickly. In truth, it’s both. Knowledge workers spend a large proportion of their time seeking information, much of the rest making sense of what they’ve found, and relatively little time in applying what they now know. As some have said, they “think for a living.” This stands in stark contrast to managers who believe that software development can be measured by the amount of time a person spends typing on the keyboard.

Shifting people’s beliefs about what constitutes work poses a huge challenge.

3. Over the next few years, what does the future of Agile look like?

I have a standard answer. In my view, Agile is in its adolescence. We don’t know what it’s capable of yet. Every month or so, I read or hear about a new model or approach that adds to the body of knowledge we have about “Agile” and what it looks like. The future of Agile is one of continued evolution and increasing efficacy in ways we can’t imagine today. Like all complex ideas, it’s usefulness will continue to emerge. It may even become known by a different name. Look for its hallmarks: humanized work with an emphasis on mastery of our craft, a focus on rapid learning and feedback, delivery of business value (sooner not faster), and close connection to customer needs (even ones the customers’ haven’t noticed yet).

4. What is your view on ‘prescriptive’ retrospectives?

I’m not sure what that term means. When I looked it up, the first url was a Christian History blog. And I didn’t find much that was useful after that. So, I’m going to take a guess. The definition of prescriptive leads to a sense of “rule-based” “right and wrong” as opposed to descriptive which is more focused on the current situation and its needs. I’m not a big fan of the focus on right and wrong. One of my favorite quotations comes from Rumi, “Out beyond ideas of wrong-doing and right-doing, there is a field. I’ll meet you there. When the soul lies down in that grass, the world is too full to talk about.”

I want my retrospectives, and everyone’s, to provide a useful focus on continuous learning and improvement for the team, its product, and the organization and customers it serves. If kaizen (incremental improvement) or kaikaku (transformative improvement) are the result, you’re doing fine, in my opinion. If your retrospectives give you no benefit, stop! Or rethink how you’re approaching improvement.

The framework for retrospectives that Esther Derby and I described in our book has worked well for me as an organizing principle for designing the meeting. Every retrospective I lead is custom-designed for that team at that time with those conditions. it describes their current state and looks for ways to make it better.

What gets taught in too many Scrum and Agile training courses, “make lists of what worked well and what we want to do differently,” doesn’t work for me. Maybe there’s some team somewhere for whom that’s effective. Not me, not mine. That truncated retrospective form is a way of pandering to organizations who want their retrospectives short (half hour) more than they want them to be useful.

5. What are the fundamental principles for any retrospective?

First, prepare in advance. Come to the meeting with a designed flow of group process activities. (Sounds more daunting than it is.)

During the meeting:
Bring people together in a way that helps them focus on the work of improvement. Esther and I called this, “Set the Stage.” Pay attention to the setting and the mindsets.
As a group, describe the situation so that every team members can view the iteration (or other period of work) from all perspectives, not just their own. We called this, “Gather Data.” My colleagues at the Human Systems Dynamics Institute and the Institute for Cultural Affairs call this “What?”-answering the question, what is the current state? what have we just experienced? I have also called this the learning aspect of the retrospective. Everyone learns what everyone else knows, has experienced, and how it impacted their work.
Spend time making sense of the “what”. In the Agile Retrospectives framework, we called it, “Generated Insights.” Others describe it as the “So What?” step. Now that we know what we know, what meaning do we make of it? This is the group thinking/analysis part–discovering implications, interpretations, significance, and evaluation.
If we’ve done a great job of #2 and #3, the next step is to choose our next improvement action or experiment or , to “Decide What to Do” or frame the “Now What?” which includes the small increment of action and how we’ll track and assess its effectiveness.
Finally, “Close the Retrospective.” End the meeting in a way that respects and honors the people and the work they’ve done, reinforces the action they chose, and helps to give feedback to the facilitator, so they can improve the way they serve the team.

Beyond that, the fundamental principle is: find a way to continuously learn and improve that actually works for the team. I don’t care whether you use our framework, the Toyota Improvement kata, Quality Circles and A3 reports, or some other process…find one that works. That’s my only prescription.

6. How important are open space sessions for Agile community?

Open Space Technology as proposed by Harrison Owen nearly 40 years ago makes a great match with the principles of Agile. Both foster empowered action and self-organization. My most recent Open Space experience ended just two days ago – Agile Open Northwest 2015 – and it was another delightful instance of community members coming together to discuss what’s most important to them right now. I find people understand Agile better after they’ve spent time in an Open Space.

We often find companies confuse Agile Fluency Model with an Agile Maturity Model? Using it as a yardstick to measure their teams. What advice do you have for them?

Agile has a problem. When we started out with Agile, people used it because it made their lives and products better. Now people complain that Agile is about meetings, top-down mandates, and wasting time. We can do better. It’s time for a change.
In response, James Shore and I developed The Agile Fluency™ Model and Martin Fowler published it, “Your Path Through Agile Fluency”. The model describes how teams grow in their understanding of Agile over time. It’s a descriptive model, because it reflects what happens in the real world, and in it’s an aspirational model, because you can use it to understand how to invest in improving your teams.
We’ve found the model very useful for helping teams, managers, and executives understand what they can get from Agile and what they need to invest in order to get those results. The model’s emphasis on concrete outcomes means executives are open—even eager—to devote the effort needed. Leaders appreciate being able to see the tradeoffs and make a strategic decision, and teams thrive when given meaningful goals and the time and resources needed to achieve them.
We hope the model is used in this spirit and not as an Agile Maturity Model. If this sounds interesting, come to my session at Agile India 2015 to find out how the fluency model can help you and your teams.

This workshop has limited seats. Book early to avoid disappointments: hhttp://booking.agilefaqs.com/agile-india-2015#workshops

Interview with Ash Maurya – Running Lean

With the increase in the consumer demand and change in the market dynamics, the number of new products that are launched in our market have increased tremendously. The passion of these young entrepreneurs have inspired thousands of young minds to develop new solutions to new/existing problems. However the success of these products are largely driven by the consumer expectation and passion is only a driving force.

Ash Maurya, a serial entrepreneur is running a 2-day workshop about building successful products at Agile India 2014. In this 2-day hands-on workshop, you’ll learn a systematic methodology, developed through rigorous testing of Lean Startup, Customer Development, and Bootstrapping techniques on hundreds of products, that will show you exactly how to build what people want.

Ash Maurya

He is the founder of Spark59 and also the author of ‘Running Lean’. Currently he is working on his new book ‘The Customer Factory’.

Running Lean

We had a short chat with him to understand his views about building successful products.

1. What is one important lesson that the large enterprises should learn from startups and vice versa?
Bringing a new product to market, whether at a large enterprise or startup, is riddled with extreme uncertainty. Most products fail.
The key to raising these odds is prioritizing learning around what’s riskiest (not easiest) in the business model.
The first phase of the journey is getting to a business model that works. This can be characterized as a “search” problem where speed is key. The best mode of operation here is the startup. Enterprises that want to explore new or disruptive innovation should model themselves after startups.
The second phase of the journey is scaling that business model. This can be characterized as an “execution” problem where systems and processes become increasingly important. Here the startup needs to mature it’s practices and can learn a lot from existing enterprises.
2. How does Lean Startup help companies to deliver a customer centric product?
The job of a business model is to create, deliver, and capture customer value.
The Lean Startup embodies the customer in every part of the process. All experiments have to end in customer learning and you aren’t making progress until you can demonstrate customer value.
It is through this continuous feedback loop with customers that we break the product development silo and build more products that people want.
3. Your Lean Canvas is an excellent tool to help companies articulate their business model in a simple format. Are there any gotchas that companies should be aware when using the Lean Canvas?
The biggest pitfall with any kind of modelling is falling into the analysis/paralysis trap. I recommend time-boxing business model creation to no more than a day and then shifting all the effort to business model validation using the other tools in the Lean Stack suite.
4. India has a budding Startup culture. What would be your advice to startups?
I truly believe we are going through a global entrepreneurial renaissance which represents an incredible opportunity for all of us.
But while we are building more products than ever before, the sad reality is that the success rate of these products hasn’t changed much.
The odds are still heavily stacked against starting a new business and most of these products will unfortunately fail.
The good news is that a lot of these big bang failures can be outright avoided and instead replaced with a more systematic approach to building successful products.
The number one reason why products fail is not because we fail to build what we set out to build but because we waste needless time, money, and effort building the wrong product.
I attribute the entrepreneurs unbridled passion for their solution to be the top contributor to this failure.
The key is shifting your perspective from having more passion about just your solution to having as much (if not more passion) for your customers and their problems.
5. What is the take away from your Running Lean workshop ?
This will be hands on workshop with part lecture and part  hands-on exercises where you will work on moving your business forward using lean techniques.
The first day will be all about modelling your business into a more more manageable and testable framework. While the second day will be all about stress testing this business model through carefully designed experiments.
By the end of this 2-day workshop, you will have an actionable plan for what to do next to move your business or product idea forward.

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2014#workshops

Interview with Lyssa Adkins and Michael Spayd – Coaching Agile Teams

The need for an Agile coach and a right channel for coaching has become imperative for many Agile organisations. This forces us to nurture a community of coaches who understand the role requirements and goes beyond the usual to tackle the implementation challenges. Lyssa Adkins and Michael Spayd are pioneers in coaching the Agile coaches to handle large enterprise problems. Their experience in life coaching and expertise in the industry gives them an edge. They have more than 15 years of experience in leading projects and organisations.

Lyssa is also trained as a Co-active coach and leader. She authored ‘Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition’ in 2010.

Lyssa Adkins

Lyssa Adkins Book

Michael is trained as a Team and Organizational coach, in co-active leadership and in executive coaching.Currently he is writing a book called Coaching in the Agile Enterprise.

Michael Spayd

Lyssa and Michael are running a workshop at Agile India 2014 for Agilists who wants to increase their overall Agile coaching skills, including in the areas of Teaching, Mentoring, Facilitation, and Professional Coaching.

We had a short chat with them to understand their views about Agile Coaching

1. What is the role of an Agile Coach in the Agile transformation journey?

Lyssa Adkins: You know Agile coach is a word that we just use generically because almost every corporation has their own version of these words. They’ll say “XP coach” or “Scrum Master” or “Agile Project Manager” or something like that. And we’re not really religious about which form or the word we use. What we care is about how the coaches help teams move beyond just getting the practices up and running and, into helping teams on their joyful and deliberate pursuit of high performance. It’s really going beyond what we would consider as a basic Scrum Master or XP coach for example.

Michael Spayd: It is, as Lyssa is saying, a pretty broad range of definitions. The word “coach” is interesting too because it’s such an overloaded term. You know, it means sports coach to some people, it means professional coach – like a life coach or an executive coach to some people, and it means kind of you having coaching by your manager which really means telling you what you need to do or you are going to get fired.And that’s created some confusion around what Agile coaches do and a really wide range of activities they do.

We’ve done some writing about that and talked about all the competencies that Agile coaches need to have. But basically they stand in a position or work in a position that’s kind of like a team leader in a certain way and kind of outside the team, helping the team, serving the team, and helping the team become a better team. Not like doing things for the team, not getting and making all the decisions for the team – anything like that, but really trying to help the team become a better team.

2. What does it take to be an effective Agile Coach?

Michael Spayd: Well this is where the term Agile coach is both overloaded and really big actually, there’s a lot of things to do as an Agile coach. So we look to impart facilitation, like professional facilitation and having skill at being a neutral facilitator of meetings and events (you know games whatever it is in the Agile environment). And help leading teams through that without getting involved in the content without voting on “Oh you should do this way” but actually helping the team get better themselves.

The thing that most people think about when they think about an Agile coach is what we call an Agile-Lean practitioner, so knowing about the Agile processes, knowing how the values relate to the principles, relate to and generate the practices, how you innovate, how you modify them in a consistent way – that sort of thing – so all the world of knowing all about Agile and Lean. That’s one big, big piece but it’s definitely not the whole shooting match.

Lyssa Adkins: The predominant role we’re playing now is to help coaches create awareness in themselves of which of those disciplines (we didn’t even go through all of them but we’ve gone through a good number of them) they have solidly and which they don’t. And how at any given moment they will choose which one serves the purposes of the transformation best.

Michael Spayd: So making for an Agile coach in terms of transforming or working with a team they have to draw on this pallet, if you think about this, because coaching, facilitation, teaching, mentoring, Agile Lean practitioner. It’s like a pallet of colors that you are painting with so to speak, and the art of it, in a lot of ways, is which one do you choose at which time to help an organization make this transition.

Lyssa Adkins: We recognize that transformation is about “transformation”. Which means you can’t consult your way into it, you can’t cajole someone into it, you can’t make them do it. It’s a lot about each individual person and how that radiates out to a whole organization. So, in the center of all of those disciplines is this thing we call the coaching stance. Which is very much just like a home base that an Agile coach comes back to as a way to help activate in other people their next positive steps towards the transformation they see needs to take place. And that’s how the results stick. That’s how an organization continues to transform once the Agile consultants have left the building. And that’s an important thing for us. I guess the higher calling of why we’re together is that Agile is this incredible positive transformation virus. It is unleashing a wave of positive change everywhere that it goes. And we believe that Agile coaches when they are well equipped are powerful transformation agents to help that virus spread in a positive and useful way. Not only for people but also for products.

 3. What are the key take-aways from your workshop?

Lyssa Adkins: Well instead of us telling you about the take-aways from our workshops, you can find the testimonials from our participants on ‘Our Impact’ page in our website.

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2014#workshops