Lean-Agile Straight Talk

Management and Trust: A Conversation with Derby and Shalloway (Twibinar)

jim.trott@netobjectives.com (Jim Trott) — Tue, 31 Jul 2012 15:46:23 +0000

Management and Trust: A Twibinar with Esther Derby and Alan Shalloway (audio of the webinar)

On July 16, 2012, Alan Shalloway and Esther Derby held a twibinar conversation on Trust and Management. Talking with each other and with attendees who participated via Twitter, they got into the important topic of trust in the organization, one of the necessary foundations for being able to scale Agile in the organization.

This conversation grew out of talks that Alan and Esther have been having about scaling Agile across teams. This quickly led to a broader conversation about trust as a necessary foundation for scaling.

Note: This webinar is about 40 minutes long.

Here are some of my notes from their conversation:

Trust grows in the doing. Alan finds that when there is an absence of trust between teams and management, it helps to have them start working together, to achieve small successes. This becomes a virtuous cycle of wins and confidence and trust. He does not always address the issue of trust head-on but lets trust emerge from what people do.
Trust is intentional. In Esther's experience, the way to engender trust is to give trust, demonstrate trust, and then to have a process for maintaining trust and nurturing it.
Trust is active. It grows from small things. Having a common vision and goal is very helpful to build trust. When there is a lack of clarity in the organization about where we are going, who our customers are, how we want to interact with customers, how we want to relate with our employees, then it is very easy for people to have hidden agendas, hidden goals that might be at odds with the common vision of the company. That is where you get into trouble. This can lead to politicking and distrust. Making the common vision explicit gets everything into the open and that can build trust. It allows for accountability. And, hopefully, it means people can make generous interpretations of the actions of others.
Workflows are really about relationships. Alan says that having explicit workflows is also helpful in this way. Making workflows explicit is not about enforcing control; rather, it is a way for the team to agree together how they want to do work. This sort of concrete discussion helps the team to gel and trust. One advantage to focusing on workflows is that they are "neutral." It is easier and less threatening to critique a process than to critique another person. Esther has another perspective. She believes that the vision and goals are most important. Without that common understanding, the organization as a whole is going to have problems. She observes that how Alan described "workflow" is not really about work definition but instead is about the relationships between people on a team. It is not the formal definitions of process that build trust. Trust emerges from the conversations and negotiations people have as they relate and aim toward the common goal.
Silos lead to distrust. They make it easy to miss seeing the common goals, to work on your own agendas, and not to value the differences that lead to creating value. It is also important to review policies to see that they reinforce trust. How often it is that policies broadcast that we don't trust our employees to work like adults.

Books and Resource Recommendations

Creating a Lean Culture by David Mann
Blog: Why not to focus on the company's culture
The Power of Losing Control by Joe Caruso
Building Trust: In Business, Politics, Relationships and Life by Robert C Solomon and Fernando Flores

Have a look at the current Net Objectives webinar series, Lean-Agile at Scale and at the Team: The Value Stream Series

Author:

Jim Trott

Topics:

Management

Change Management

Transitioning to Agile

Agile

Lean-Agile

Blog Type:

Podcast

Product Portfolio Management: Essential for Agile at Scale - PODCAST

jim.trott@netobjectives.com (Jim Trott) — Thu, 31 May 2012 01:26:31 +0000

Product Portfolio Management: Why It Is Critical for Agile at Scale

This is going to be the topic of a webinar on June 18, 2012.

We frequently hear about organizations who have had good success with Agile at a team level - good productivity gains, higher quality code, good morale - but then they have problems getting Agile to work "at scale." They have a hard getting collections of teams to work together. They don't see the hoped-for impacts on the bottom-line across the portfolio of work to be done.

In our consulting work and our dialog with other consultants, we have learned that success at scale requires attention to four essential aspects:

Actively managing the product portfolio
Delivering work to the team
Intentionally managing the web of relationships with multiple stakeholders and teams
Attending to the final integration

All four of these are critical for success in product development. They each affect the other. Of course, you apply as much of the model as you need while knowing the bigger view so you can see where you are going. Below are notes about each of these.

Product Portfolio Management. How do you ensure that teams are working on the right things?
Managing the Web of Relationships. Larger, more complex the organizations usually need to have different people managing the relationships:
- Someone who is looking after the interests of the Business Stakeholders and executives. (This is often called a "Product Manager" and we call it "Business Product Owner")
- Someone who is focused on driving teams (This is often called a "Product Owner")
Delivering work to the team. Creating the context and loading the teams.
- How do you manage the Work-in-Progress so that teams are loaded in a way that work will flow at pace that is sustainable, efficient, and constantly delivers value. This involves a systems-orientation.
- An issue here is getting them to collaborate effectively. Scrum of Scrums is one approach that Agile teams have tried for collaboration among teams but it has met with only limited success. This is because teams are naturally "tribal"
- A more successful approach is to set up the system in a way that reduces the amount of collaboration that teams have to do. The webinar discusses approaches to do this using a common backlog.
Final Integration. What are the most significant constraints we face in software development?
- Usually, they are at the end of the process: integration and testing. Think about these early in the process. The main
- Constraint: The ability of teams to stay in sync? If they can stay in sync, then final integration should become easier.
- Dynamic Feature Teams is one approach to address final integration and staying in sync. The webinar will present a case study how this works.

Learn to See: Beware of your Biases!

In the mid-1800's, Ignaz Semmelweis discovered that hand-washing could reduce mortality rates in childbed fever to below 1%. Yet, despite repeated demonstrations and publications, the medical community rejected his ideas because they conflicted with the established scientific and medical opinions of the time. They did not yet know about germ theory. See http://en.wikipedia.org/wiki/Ignaz_Semmelweis

In some ways, we are like that in software development. "Flow" may be one of those essential laws in software development that we do not yet understand. And so we have more complex approaches.

Things may not be self-evident but once they are pointed out, they become intuitive.

Lean-Agile at Scale and the Team: The Value Stream Series

The Lean-Agile at Scale and the Team: The Value Stream Series addresses closing this gap between knowing and doing. It addresses a dozen areas that will significantly improve the flow across the value stream, shortening the time to market from when an idea is conceptualized until it can be put to use by customers. Attending to these things offers great benefit both to development teams and to the Business. And to continue doing so in a sustainable way.

You can get more information and sign up at www.netobjectives.com/lean-agile-scale-and-team-value-stream-series

Here are the topics covered in this webinar series:

Lean startup
Product portfolio management
Scrum, Kanban, and XP practices
Technical Agility
The Role of the Product Owner
Acceptance TDD
Enhancing and Extending Scrum
Essential Skills for the Agile Developer
Scaling Agile with Lean
Attending to the culture in your Agile transition
Operations and Agility

Credits

Music by Bill Chushman ghostnotes.blogspot.com

Webmaster: Andrea Bain

Author:

Topics:

Blog Type:

Podcast

A New Season of Lean-Agile Straight Talk, A New Webinar Series

jim.trott@netobjectives.com (Jim Trott) — Thu, 10 May 2012 22:47:03 +0000

A New Season and a New Webinar Series

It is springtime in Seattle, a good time to start anew. Since the last season of Lean-Agile Straight Talk, we have been writing and consulting and coaching and working with many clients. We have greatly deepened our understanding. To start the new season of Lean-Agile Straight Talk, I asked Alan Shalloway, CEO and Founder of Net Objectives, to start sharing some of what is on his mind right now based on what we have been learning. If you know Alan, you will know that one of his main things is the gap between knowing and doing that is in our industry, we know a lot of what to do but the doing is often not yet in common practice.

And this is leading Net Objectives to offer Lean-Agile at Scale and at the Team: The Value Stream Series, a new webinar series that helps you know what to pay attention to to close that gap.

I'm looking forward to a new season of conversations. I welcome your comments. Drop me a note at jim.trott@netobjectives.com

Complex Stuff and Complicated Stuff: Doing what we know would help

Software product development is among the most challenging of human endeavors. It is a system of many elements and stakeholders with interests, forces, and needs that must be addressed. Markets and people and human nature being what they are, there will always be significant aspects of product development that are "complex" - not fully knowable so we have to observe and try to predict. But not everything is that way. We have learned much about what is required to develop effectively, to be able to deliver value sustainably to the organization. This means that great chunks of this effort could move into the realm of "complicated" work - it still is not simple, but we know what to do. Examples include XP engineering practices, Acceptance Test-Driven Development, Design Patterns, how to manage flow, the importance of making work visible.

Doing the complicated stuff the right way would go a long ways toward more sustainable, more valuable, less painful development work. We know this works because we are seeing this in our own coaching and in conversations with other coaches and consultants.

The challenge before us is that even though We know what to do, it is not yet in common practice.

Lean-Agile at Scale and the Team: The Value Stream Series

We are introducing a new webinar series addresses closing this gap between knowing and doing. It addresses a dozen areas that will significantly improve the flow across the value stream, shortening the time to market from when an idea is conceptualized until it can be put to use by customers. Attending to these things offers great benefit both to development teams and to the Business. And to continue doing so in a sustainable way.

The series begins on May 22, 2012 and you can sign up at www.netobjectives.com/lean-agile-scale-and-team-value-stream-series

What is covered in this webinar series?

Lean startup
Product portfolio management
Scrum, Kanban, and XP practices
Technical Agility
The Role of the Product Owner
Acceptance TDD
Enhancing and Extending Scrum
Essential Skills for the Agile Developer
Scaling Agile with Lean
Attending to the culture in your Agile transition
Operations and Agility

Credits

Music by Bill Chushman ghostnotes.blogspot.com

Webmaster: Andrea Bain

Author:

Topics:

Blog Type:

Podcast

Notes from the LeanSSC Atlanta 2010 conference

jim.trott@netobjectives.com (Jim Trott) — Fri, 07 May 2010 19:21:30 +0000

Notes from LeanSSC Atlanta 2010

In this show, Alan Shalloway shares his impressions from the inaugural conference of the LeanSSC which was held in Atlanta, Georgia. LeanSSC stands for the Lean Software and Systems Consortium. This is a consortium of practitioners and experts from many organizations who are committed to assisting enterprises that depend on software – from start-ups to those that build complex, software intensive products, systems & services – with the application of Lean Thinking throughout the enterprise.

The conference website is at Atlanta2010.LeanSSC.org and we are busily posting presentations and video from the conference to give you a notion of the many topics that were discussed.

The speakers at this conference were from the top notch of our industry, people who have done the hard work of bringing these good approaches to the enterprise. There was a lot of talk about what works and what doesn't work. It was great to be among like-minded people who could debate passionately about the issues but coming from a common foundation.

We talk about who was there, what was surprising, and some of the future vision that speakers shared. Amidst all the diversity was that there were common themes: respect for the knowledge of people, the importance of paying attention to key principles, maintaining a common vision.

We hope you can come to the next conference: either this this fall in Europe or next year in Los Angeles!

This is a movement. It is open and driven by a broad spectrum community of practitioners, making knowledge available to industry.

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

Reflections on a New Year: Part 2

jim.trott@netobjectives.com (Jim Trott) — Wed, 17 Feb 2010 22:49:32 +0000

Reflections on a New Year: Part 2

We continue reflecting about the trends in 2010 and areas in which Net Objectives will be investing some of its energy and thought as we help to serve our partners and customers. In this podcast, we talk more about transitions: the team that is involved, how it helps to think about the entire value stream.

Introducing change requires a partnership of business, management/leadership, and the team. No one has the complete picture. All three have to be engaged to succeed. It is driven by the business. Management leads, coaches, guides. The team sees its process and applies technical skills.
The goal is to introduce change in a way that is most effective for the whole value stream. This guides you in deciding when, where to introduce what kind of change. The good news is that it doesn't have to be (only) the team that has to be the focus of change efforts.

This is a break in the walk-through of Lean-Agile Software Development: Achieving Enterprise Agility. We will turn back to it in mid-February.

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

Going beyond Scrum, Part 2

jim.trott@netobjectives.com (Jim Trott) — Wed, 17 Feb 2010 22:43:18 +0000

Going beyond Scrum: Part 2

Chapter 5 of the new book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses "Going beyond Scrum." This is a big chapter, so we are taking it in two parts. Last time, we talked about the importance of optimizing the whole and taking a holistic view of the team if you want to be able to impact the enterprise. Now, we turn to two more key factors: the importance of managing your workflow and the value of accessing and using the good practices that have already been learned by others.

In the book, we touched on the idea of Kanban for Software Development and it deserves some more consideration. We also cover resources and thought leaders to pay attention to as you look toward moving beyond (classic) Scrum to the enterprise.

Kanban is an approach to managing work by focusing on the flow of work. How you organize the work - using a team-based swarming approach or a work-phase approach - is left to you; what is important is that you manage the amount of "work-in-progress" (WIP) that the team has going on at any time. And the organization manages WIP intentionally, by policy. Limiting WIP helps reduce delay. Improving the process, then, is focused on reducing anything that impedes the flow of work. That is how you choose what to improve.

Kanban is appropriate even in your Scrum practice. It is truly remarkable how well it helps to have a defined workflow and process improvement approach.

The Scrum Clinic

In our years of coaching Scrum, we have learned some good practices that every team seems to have to learn. It makes sense to learn them early rather than forcing the team to have to discover them on its own (per the classic Scrum approach). Why reinvent the wheel when there is already so much more to discover.

We pulled together essentialresources into one place, "The Scrum Clinic," which you can access for free. Each resource is small "chunk of high-leverage knowledge" that will get you going in your own use of Scrum much more quickly.

Examples include:

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

Going beyond Scrum, Part 1

jim.trott@netobjectives.com (Jim Trott) — Wed, 17 Feb 2010 22:25:10 +0000

Going beyond Scrum: Part 1

Chapter 5 of the new book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses "Going beyond Scrum." This is a big chapter, so we are going to take it in two parts. First, we want to consider the implications of the maturing and segmentation of the Scrum community and two key factors required for being able to scale Scrum to an enterprise: taking a systemic approach and looking at the team holistically, how it fits with and must work within the organization. Next time, we will look at Kanban, managing the flow of work, and using the Scrum clinic to (reusing) good practices learned by others.

Over the last decade, the Scrum community has matured greatly. And, as often happens, it has begun to segment as people discover new, alternative paths that the founders never imagined. Sometimes, that means people move on from the original group When it comes time to investigate or add new profitable bodies of knowledge. I think that is what you see in the various Scrum,

Lean-Agile, and Kanban communities. New ways are being explored. Clearly, there have been situations and teams where classic Scrum worked very beautifully and helped create a lot of value for an organization. It seems that that population has mostly been mined, that that market has been pretty much saturated. Going forward, there is a need to be able to help teams and organizations where more is needed, where classic Scrum, by itself, is just not enough.

This chapter touches on two key understandings or beliefs that are required to be able to go beyond (classic) Scrum. One is that you can (indeed must) take a systematic approach. The other is that a team-centric focus is not sufficient.

A systematic approach. One of the new approaches (which is not really new but reaches back to solid principles) tries to take a more systems-thinking approach, thinking along with Don Reinertsen that productivity comes by looking at PEOPLE X PROCESS. That is, the whole system - people and process - works together and neither can be ignored. Lean calls this "optimize the whole."

Thus, as we have gained experience with Scrum - and especially as we have begun to incorporate it with other disciplines such as Lean, Test-Driven, patterns, and the like, we are learning what behaviors and patterns teams need to be effective and what processes help them. And once learned, why not use them again and again rather than forcing each team to have to discover them again on their own? That is part of the driving force behind this chapter and this book.
A holistic view of the team. The second thing is to look beyond the individual team to how how they must interact with each other.

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

Reflections on a New Year: Part 1

jim.trott@netobjectives.com (Jim Trott) — Tue, 19 Jan 2010 07:00:00 +0000

Reflections on a New Year: Part 1

The beginning of the year is a natural time to think about what is coming in the year. Alan Shalloway shares his thoughts about some of the areas in which Net Objectives will be investing its energy and thought as we help to serve our partners and customers. In addition to our normal areas of training and coaching in Lean, Agile, acceptance test-driven development, design patterns, and process improvement. But what else? In this podcast, Alan and I talk about two key areas where we are going to be investing our energy: Kanban and what it takes to help enterprises and teams make the transition.

Kanban. We believe in Kanban for software development. We have joined with David Anderson and others to help foster the community of those who want to explore how to use this, the good practices, the deep principles - you might call it the "science" of Kanban software engineering. What it takes to realize the tremendous potential benefit of this approach.

Two key communities to look into are the http://www.limitedwipsociety.org/ in the UK and the LeanSSC.org, which is more worldwide.
Transition. How to help enterprises and teams make the transition, the change to greater productivity in software development: managing the introduction of change to be productivity

What prompted this was a training class with David Anderson of D.J. Anderson Associates. David is a leading expert in Kanban as applied to software engineering. I recommend his course for anyone who wants to sharpen skills in coaching Kanban because he has seen it all.

This is a break in the walk-through of Lean-Agile Software Development: Achieving Enterprise Agility. We will turn back to it in mid-February.

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com/ and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

Introducing Kanban for Software

jim.trott@netobjectives.com (Jim Trott) — Tue, 22 Dec 2009 01:46:03 +0000

Introducing Kanban for Software

Phil Cave is a new consultant with Net Objectives. Phil has a long history with Lean, XP, Scrum, and Kanban. He has worked at all levels: developer, lead, manager, division manager, vice-president, Lean coach. Phil just got back from Krackow, teaching our Lean Software Development course. Half of this course involved helping them integrate the Kanban technique into their Lean-Agile software methodology. Kanban is gaining ground as an important technique for Lean-Agile groups because it is widely applicable in both process-oriented and specialty-oriented shops. It does not require fundamental shifts in work (unlike other Agile methods) if that is not appropriate for you. It is something we need to learn more about.

Here at the end of the year, I want to express how grateful I am for you. I hope you have a blessed holiday and a warm new year. I look forward to being with you again in January.

Recommendations

Lean Software and Systems Consortium: www.leanssc.org

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

Chapter 4 - Lean Portfolio Management

jim.trott@netobjectives.com (Jim Trott) — Mon, 09 Nov 2009 23:08:33 +0000

Chapter 4: Lean Portfolio Management

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.

This show focuses on Chapter 4, Lean Portfolio Management. The premise is that managing the work you are feeding the team is more important than how well the team works.

What you want is for the business to drive small increments, giving the development team just enough to get value out at a sustainable pace. It is possible to do a better job planning! There are many techniques and that is the subject of another book. However, just knowing about shorter planning increments does help. Smaller, well-defined things running through the pipeline is better than big batches that clog things up.

There is another benefit. We build these big project plans and even though we know they won't work as laid out, they seem to take a life of their own. If someone proposes a change request, it is a huge effort because those plans are so cumbersome. Lean portfolio management cuts through all of this! Since we are planning in shorter cycles, if a new change comes through, we just compare it with all of the other requirements in the next cycle and insert it if has higher business value. Those change boards - so bedeviling - become a thing of the past.

About Lean-Agile Software Development: Achieving Enterprise Agility

The motivation of this book is to create a bigger picture what teams transitioning to agile need to do. Yes, teams need to understand the mechanics of the approach to get working, but there is more. Management needs to understand how to help teams work together. Business leadership prioritizing the right things to be working on. And there is a need to ensure technical quality so that development can be done in a sustainable way.

We also want to introduce Lean and how it applies to the transition. We don't believe "scaling up" is a very effective approach. Rather, taking a more holistic view is needed to get success. That is how Lean thinking helps.

This is not a book for experienced practitioners but for those who are picking Agile, Scrum, or Lean for software development. We expect you do understand a bit about Agile but not anything about Lean.

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

Chapter 3 - The Big Picture

jim.trott@netobjectives.com (Jim Trott) — Mon, 09 Nov 2009 20:12:21 +0000

Chapter 3: The Big Picture

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.

This show focuses on Chapter 3, The Big Picture. We talk about why, if you want to see improvements in throughput in product development, it is vital to focus on the entire value stream, the entire process from when an idea is formed until it reaches the user or customer. In fact, a transition to Lean-Agile involves agility in at least four areas.

It is not enough just to focus on helping developers. In order to see improvements in the throughput for product development, you have to look at the whole value stream: the entire process from when an idea is formed until it reaches the user or customer. You want to focus not on where you are spending your money but where you are spending your time. And this means looking at the time you spend waiting as well. Keeping people busy can be counter-productive if it keeps them from being available on the most important things. Think of it this way: What is the impact if projects are having to wait on the most productive, highest value people just because they are working on too many things?

Agile coaches often have a technical background. This means that too often, Agile deployments focus chiefly on helping developers. This is good and necessary but it is not sufficient. If delays are being caused elsewhere, then improving development will only offer marginal gains. When you are transitioning, you have to look at improving agility in four areas:

Team agility
Technical agility
Management agility
Business agility

Of course, where to start depends on your situation.

About Lean-Agile Software Development: Achieving Enterprise Agility

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

Chapter 2 - The Business Case for Agility

jim.trott@netobjectives.com (Jim Trott) — Mon, 09 Nov 2009 19:20:45 +0000

Chapter 2: The Business Case for Agility

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.

This show focuses on Chapter 2, The Business Case for Agility. We cover the five most important reasons for going Agile and how it is that understanding the whys of Agile helps you with this transition.

It is important to understand the reasons for going Agile. Perhaps as important is understanding the whys of Agile: It helps you navigate your journey as you make the transition. Here are five of the most important reasons for going Agile:

Deliver value quicker.
Getting to market quicker is good. It is often possible to deliver some important features in stages. It allows faster return with less investment and that is always good!
Helping customers discover what it is they need.
Agile is best understood as a process that helps customers and developers discover in stages what it is that software should do. It helps customers focus on specifying what they know and avoid having to guess about requirements that they are not yet sure of. The most important book that covers this is Software by Numbers by Denne and Clelland-Huang.
Better project management.
Waterfall tends to steer projects based on milestones, which is an inaccurate guide about where a project really is. Agile steers based on working code which is much more accurate.
Improving process faster.
It would be better if teams learned continually but at least Lean-Agile has them learn after each iteration. Short iterations let teams learn quickly what is working and what is not. It is much better to learn lessons after two weeks rather than after two months!
Letting your design emerge based on what you are learning.
While it is often ignored, there is also a technical reason for going Agile. With some discipline and appropriate tools (automated regression testing), it is possible to avoid up front design (almost always wrong or incomplete) and allow design to emerge based on what the team is discovering. This is powerful. There are two good books that describe why this is so:

- Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
- Agile Software Development, Principles, Patterns, and Practices by Bob Martin

About Lean-Agile Software Development: Achieving Enterprise Agility

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

Chapter 1: A Developer's Guide to Lean Software Development

jim.trott@netobjectives.com (Jim Trott) — Sun, 01 Nov 2009 16:07:48 +0000

Chapter 1: A Developer's Guide to Lean Software Development

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.

This show focuses on Chapter 1, A Developers Guide to Lean Software Development. We start to answer the question, if Lean's goal is to focus on speed, quality, and low cost. How do you do it?

In the past, the approach has been to try to make every step and every person as efficient as possible. That doesn't work. Instead, you have to look at optimizing the whole process. It is different than efficiency and cost; in fact, lowering cost can increase speed to market and lower quality.

Lean says the better approach is to focus on removing delays.

We want to focus on the time between the idea is conceived until the customer can consume it. This involves realizing that product development is a conversation between developers and customers to discover what is required. Customers don't always know what they need. As much as possible, you want your process to improve the learning and feedback that is taking place so that customers can focus on what they really need.

What is needed? Focus on removing delays, removing waste in the overall process. For example,

Get feedback from the customer quickly.
Write tests first. Then you immediately discover when bugs appear.
Detect integration issues quickly.

The bottomline is that We want to make value flow through the organization quickly and remove anything that causes delay.

Finally, practices change depending on the context. How do you know the practices you are doing are good? By comparing them with the foundation lean principles. Teams have both responsibility and guidance for their work. That is the perspective they need.

About Lean-Agile Software Development: Achieving Enterprise Agility

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Author:

Jim Trott

Blog Type:

Podcast

An Overview of Two New Books

jim.trott@netobjectives.com (Jim Trott) — Mon, 12 Oct 2009 19:40:06 +0000

An Overview of Two New Books

In this show, we give overviews of two new books by Net Objectives which we think you will find helpful: The Lean-Agile Pocket Guide for Scrum Teams and another is Lean-Agile Software Development: Achieving Enterprise Agility. We talk through both of these books: their motivation, their contents, why they are useful. In the next podcast, we will talk about the key ideas in each chapter by chapter of Lean-Agile Software Development, the ideas we have found is truly needed in order to be able to achieve enterprise agility.

The Lean-Agile Pocket Guide for Scrum Teams

The Pocket Guide fills the gap between one of those 10 page ("marketing") overviews of Scrum and the thousands of pages that have been written on various good Scrum practices.

In our work, we found there was a need for a concise statement of what scrum is and a convenient distillation of the best practices. It also includes some techniques not traditionally taught in Scrum but which are very helpful. In 200 pages, it is a great tool to remind you what needs to happen from beginning to end of product development. Lots of checklists and templates to help you think.

Some of our clients have found this tool so helpful that they have created a "private label" version of the pocket guide for their own use. It served as a baseline for their own process. And we are willing to do that with others. If you are interested in this for yourself, drop us a note.

For more information see the resource page for the pocket guide.

Lean-Agile Software Development

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

A New Series

jim.trott@netobjectives.com (Jim Trott) — Mon, 28 Sep 2009 22:04:39 +0000

A New Series

This podcast kicks off a new series for Lean Agile Straight Talk. We have been busy finishing several books focused on Lean-Agile. One is called the Lean-Agile Pocket Guide for Scrum Teams and another is Lean-Agile Software Development: Achieving Enterprise Agility. We are proud of both of these books and wanted to introduce them to you. In this show, Alan Shalloway and I talk about the motivations behind these books, what is going in in the world of Lean and Agile software development and why they are needed. The next show will give a rundown of the pocket guide. After that, we will talk through each of the chapters in Lean-Agile Software Development. Each of these chapters has good, core concepts that we want you to know and this approach gives us a game plan for covering all of them.

Each of the books Net Objectives offers aims to address the question, "What do people need to know to succeed in their role to do product development?" In a nutshell, we describe Lean-Agile with the phrase, Make-Value-Flow-Sustainably.

Make. How do developers create software at the team-level? In the past, "making" was where the challenges were.
Value. What does the business need? How do we get them to drive what really needs to get done?
Flow. How do you get what multiple teams create to flow through the organization? Learning to work together, coordinating work.
Sustainably. How to keep writing code so that it is always of sufficient quality, so that we do not keep incurring technical debt. And how to keep the organization growing in a healthy way so that it can continue to do the work.

Even if you find a technique, such as Scrum, that works well at a team-level, it does not always work in every context. And, we have learned that trying to "scale" Scrum to the enterprise is not the correct approach to achieve enterprise agility. Understanding the principles helps you know what to do when confronting situations you have not yet encountered. And that leads to proficiency in this field.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Redefining Lean

jim.trott@netobjectives.com (Jim Trott) — Fri, 22 May 2009 20:48:24 +0000

Redefining Lean

Lean Software Development is founded on Lean. But what is "Lean"? Some have said that "lean is just what Toyota does." That is not much of a definition and is not even accurate, although Toyota does do Lean. It is also not accurate to say that Lean is focused on manufacturing, although Lean is now widely used in manufacturing.Lean is not even principally about physical product even though most of the examples of Lean are in the physical world.

No. It is better to see Toyota manufacturing and Toyota product development as just examples, as manifestations of this way of thinking we call Lean. Here is one good way to think about what is going in in Lean: There is Lean Science, Lean Management, and Lean Knowledge Stewardship.

Lean Science: There are rules and principles that are present, observable, can be used to make predictions, and we can adapt and learn based on what we test and observe. The most flexible approach is to understand the Why that is behind the practices. This is how Don Reinertsen has helped us, identifying the fundamental rules.
Lean Management: How to help the organization take advantage of the science and how to remove the problems people have.
The manager is involved, neither hands-off nor command-and-control. Manager's role is education, helping people know how to think, how to see problems and how to think about the system, and also to set direction. Using visual controls helps managers see when process is going awry and there is a need to intervene, when to educate.
- Note: Jim Womack underscores this in his webinar, The Role of Leadership in Lean
Lean Knowledge Stewardship: How to discover, share, adapt, apply, and take care of the knowledge we have in the organization. There are techniques such as A3, Kaizen, AAR/Retrospection, Root Cause and 5 Whys, Value Stream Maps,

Make your plans now to attend the UK Lean Kanban conference in September. For information, see www.ukleanconference.com

Recommendations

By Don Reinertsen
- The Principles of Product Development Flow: Second Generation Lean Product Development
- Managing the Design Factory
By Corey Ladas
- Scrum-ban

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Report from Lean Kanban 2009

jim.trott@netobjectives.com (Jim Trott) — Mon, 11 May 2009 22:07:03 +0000

Report from Lean Kanban 2009

Kanban is an emerging practice in Lean software development. Founded on solid principles of flow and utilization theory, it seems to address many of the issues people have had with Agile approaches. Over the next few years, Lean Kanban is going to become an important part of the software professional's toolkit.

The Lean Kanban Conference 2009, May 6-9, 2009 in Miame, brought together practitioners and thought leaders to discuss how to help the community go forward. This podcast is a report by Alan Shalloway about what he, Guy Beaver, and Alan Chedalawada (all from Net Objectives) learned from this special event.

Over the next few weeks, Alan will be posting some blogs about what he learned at the conference. See blogs.netobjectives.com. It will be the topic of several upcoming podcasts on Lean-Agile Straight Talk.

You can learn more about this conference at http://miami2009.leanssc.org/

And make your plans now to attend the UK Lean Kanban conference in September. For information, see www.ukleanconference.com

Recommendations

By Don Reinertsen
- The Principles of Product Development Flow: Second Generation Lean Product Development
- Managing the Design Factory
By Corey Ladas
- Scrum-ban

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Three Things You Gotta Know

jim.trott@netobjectives.com (Jim Trott) — Sat, 28 Mar 2009 05:18:26 +0000

Three Things You Gotta Know

Lean is a pragmatic framework for absorbing principles and practices that other people have learned and putting them to work in large organizations. It can feel overwhelming. It is rich and there are many, many techniques and practices. It is always growing as it absorbs more good practices. That's why people can make careers out of Lean.

But you don't have to know all of Lean before you can get started. And you don't have to even be committed to becoming Lean to get the benefit from using Lean a little. In this show, Alan Shalloway discusses some of the essentials that you do need to know in order to get started.

The things you have to know about Lean include:

Look at TIME not Resource Utilization. In mass production, you are trying to minimize the resources expended per unit of work. In Lean, you are trying to minimize the time it takes for the Idea to turn into something that returns value to the organization from using it (using it in the business or selling it).
Errors usually arise from defects in a system, not poorly performing people. We don't aim for blame but we do aim for deep understanding about what happened.
Management plays an important part in process improvement The proper role for management is neither command-and-control nor should be teams be "protected" or isolated from management. Rather, management is responsible for helping the team to see and how to think. They ask intelligent questions, question them when they are not following process, help them drive to how to solutions.
Management creates the context within which problems can be addressed.

Recommendations

The Role of Leadership in Lean (by Jim Womack and the LEI)
Lean Kanban 2009 conference in Miami May 6-8, 2009. Join David Anderson, Josh Kerievski, Peter Middleton, Alan Shalloway, and other industry thought leaders as we consider together the next wave of software management and leadership. It offers the chance to interact in a small attendee/speaker ratio.

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Getting to the Benefit

jim.trott@netobjectives.com (Jim Trott) — Wed, 18 Mar 2009 19:43:11 +0000

Getting to the Benefits

It has been estimated that 75% of companies undertaking Scrum are not experiencing the benefits they expected. Why do you suppose this is? Why don't we take time to stop, observe, and improve our processes? Why is lean perhaps a more natural starting point for the enterprise?

These are some of the questions explored by Alan Shalloway in today's podcast.

But first, Alan invites you to come to the Lean Kanban 2009 conference in Miami May 6-8, 2009. Join David Anderson, Josh Kerievski, Peter Middleton, Alan Shalloway, and other industry thought leaders as we consider together the next wave of software management and leadership. It offers the chance to interact in a small attendee/speaker ratio.

It promises to be a powerful time. To learn more, visit the Kanban Dev Yahoo user group.

Why aren't organizations manifesting the promise of Scrum?

Ken Schwaeber says that 75% of companies who try Scrum do not manifest the problems of Scrum. This means that they do not get the benefits they thought they would. Why not?

Scrum is a lightweight methodology that exposes impediments so you can fix them. Too often, rather than fixing them, teams just accommodate the impediments. and that is a problem. Why do teams do that? They are beset by the tyrrany of the urgent. By the time they have time to reflect, the next problem is there and they have to move on. They just don't have time to stop!

Why don't they stop to look? Because they are starting at the wrong end: at the team-level and then think about how to "scale up" and that is hard to do. It just leads to increasing levels of complexity. How much better it is to start with something that begins at the enterprise level

The benefit of Lean is that it offers a better starting point. People don't talk about scaling up Lean because Lean already starts at the enterprise level. That is its natural environment.

We think of Lean this way:

It is a pragmatic framework for absorbing principles and practices that other people have learned and putting them to work in large organizations.

You could see Lean as having absorbed Agile/Scrum practices into the Lean way of thinking (as well as seeing Scrum as manifesting Lean principles to the specific context of teams creating software). What matters is not where the practices came from but rather that they come into the enterprise in a way that lets them be put to work broadly: Testing it in concrete work, improving it with basic lean principles as needed, tossing it if it doesn't work.

Recommendations

Lean Kanban 2009 conference in Miami May 6-8, 2009.

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Scrum and Management: Planning and Focusing

jim.trott@netobjectives.com (Jim Trott) — Tue, 23 Sep 2008 20:36:20 +0000

Scrum and Management: Planning and Focusing

Over the last several years, teams of developers have been trying Agile and getting success at their level. Now, management is getting engaged, both to figure out how to do this across divisions and the enterprise, as well as how to do a better job in less-than-simple situations that most enterprises face.

There have been notable examples where things did not go as well as expected when teams face complexity, where the fit is not exactly good, where maybe the initial approach taken was just too simplistic. It is management's job to help teams look at ways to improve.

This is why at conferences, we are encountering more and more mid-level managers. And they are asking very different sorts of questions than technical, development teams ask. This is stimulating and exciting. Clearly, Agile is beginning to enter the mainstream as a better way to manage software product development.

In this podcast, we will touch on two topics Alan that are concerns for management: Release Planning and Focus.

Release Planning

For example, one of Alan's talks at SQE focused on User Stories. Now, typically, developers want to know about how to use User Stories to write features and code. Managers, on the other hand, ask questions about how to get User Stories in the first place, how to manage them, how to use them to create more business value.

This is a great question. It comes from the perspective about why we are doing something rather than what we are doing next.
Our approach, which is covered in our Agile Analysis course, uses Minimally Releasable Feature Sets.

Here is an example. Suppose you are embedding graphic presentation of data streams on a web page and your customer is very particular about how the graphics look.

Looking just at features, you might specify a releasable feature is that you provide a histogram, which is a useful type of chart. A second releasable feature might be a pie chart. Another might be choosing colors. And so forth.
Each of these features might involve many stories.

The question is what is the minimal set of releasable features required before giving it to the customer? From a technical standpoint, you might want to have them all done first. It feels less risky, technically, and may make for a greater initial spalsh in the market. But what if, instead, you provided a basic histogram that let the customer validate the entire data collection and display process and the rough placement on the web page? And, with that basic system, they could begin showing it to early adopters in the marketplace and thus begin to establish market penetration?

Which option provides the most business value? How would you feel if you targeted release of all of the features in 6 months only to find that your competition promised to release half of the features in 3 months with the rest of the features in another 3 months. Would that put you at a competitive disadvantage?

There might be good arguments for various alternatives. The point is that as a product development team, you need to have the conversation and not make assumptions. The outcome of your conversation will be the minimal set of features required for a release.And then you can still talk about how you will package the features into the final release to the customer.

This bringing the business perspective to Agile release planning is a needed corrective to what many Scrum teams do. Too often, they dive right into stories and then try to coordinate with Epics and Themes. This local team approach is, perhaps, too narrow of a perspective; it cannot address the portfolio of products that the business needs to be working on.

Iteration Planning

Now, it is different when it comes to planning an iteration. Now that you have specified the minimal set of features that will go into the release, you are not constrained to work on one feature and then another. You are not required to work according to adding business value iteration by iteration (remember, business value comes with releases, not with iterations). Instead, you select work from across the set of features, doing whatever is required for the team (or teams) to make progress toward the release goal. Your selection criteria is based on other sorts of factors, such as:

maximizing feedback
mitigating risk through architecture
mitigating risk of teams working together
minimizing contention for resources

This is consistent with the Lean notion of "optimize the whole."

The Right Focus

One of our customers is a defense contractor, making missile systems. In one of my classes, I asked the students what their responsibility was. One bright student piped up, "we are responsible for making missiles perform reliably. They need to launch when they are supposed to launch and not launch when they are not supposed to. They are supposed to follow the proper flight plan to the right target and then go off when they are supposed to go off. That is our responsibility."

Exactly right!

As software developers, we are responsible for the larger picture. Writing software is part of what we do to fulfill that responsibility.

Naive implementations of Scrum attempt to protect teams from management. This is sad because too often, teams quickly end up focusing on local issues. One of management's jobs is to help teams figure out where best to focus. The proper and more powerful uses of Scrum is when management and teams are working together.

Recommendations

Training by Net Objectives

Lean-Agile Enterprise Release Planning

Reading

Software by the Numbers by Mary Denne and Jane Cleland-Huang
Creating a Lean Culture by David Mann

Music used in this podcast by Kevin McLeod at www.incompetch.com

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

alshall

Blog Type:

Podcast

Avoiding Coupling and Using Mocks (Webinar)

jim.trott@netobjectives.com (Jim Trott) — Tue, 23 Sep 2008 19:29:53 +0000

Avoiding Coupling and Using Mocks (audio of the webinar)

A webinar on September 02, 2008 presented by Alan Shalloway discusses how, in Agile projects, neither full up-front designs nor no design proper. This webinar discusses some techniques for decoupling modules early on. In other words, although we may not know how things will change, we often know of dependencies between modules that will morph over time. He presents three case studies:

Decoupling informational dependencies between components
How to define the API for a component being built by one group and used by another
Using mocks to never be blocked - avoiding delays caused by dependencies of different tiers

The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

Author:

alshall

Blog Type:

Podcast

Understanding Why Scrum Works (Webinar)

jim.trott@netobjectives.com (Jim Trott) — Tue, 23 Sep 2008 19:25:39 +0000

Understanding Why Scrum Works (audio of the webinar)

A webinar on September 02, 2008 presented by Alan Shalloway discusses why Scrum works and how Lean's metaphor of Fast-Flexible-Flow can be used to modify standard Scrum practices as needed. Additionally, Scrum#'s enterprise view and Lean Management philosophy will be the basis for creating an Enterprise/Organization wide team to manage dependencies across teams without command and control.

This webinar covers:

Why Scrum works
How Lean-Thinking can identify root cause of problems
How to use Lean-Thinking to eliminate delays
Breaking down the silos between development and Quality Assurance
How to coordinate multiple development teams so that they work together - going beyond Scrum-of-Scrums

The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

Author:

Jim Trott

Blog Type:

Podcast

Database Agility

jim.trott@netobjectives.com (Jim Trott) — Tue, 23 Sep 2008 19:12:51 +0000

Database Agility

Databases are central to almost any software development project of any size. Developers have been gaining big improvements as they adopt Agile approaches: higher quality, more satisfaction, delivering more value to customers. It seems time for database developers to begin to experience the same gains!

But database development is special. It is not like just copying new bits into the environment. Databases need to retain their identity and the data that are in them. They have history and investment and must survive. Transitioning change is much harder and requires more care.

Is it possible to use iterative, Agile approaches with databases?

Yes it is. This podcast describes the landscape for doing so. Early adopters of this approach have learned the key principles involved and tools for testing and transition management are now available. Training is also available to equip teams with the new skills and ways of thinking that are required in order to be successful.

This podcast features a conversation with Max Guernsey, an associate trainer with Net Objectives. He has been developing professionally for 10 years and been consulting in Agile database development for the last year. He has turned this expertise into a course - really an on-site, practical boot camp - to help teams successfully incorporate this approach into their development practice. It is called the TDD Database Boot Camp.

As you might expect, Test-Driven Development (TDD) is going to be as central to this approach as it is to Agile development in general. The trick is to see what what this means in the database world. As Max touches on in this podcast, it goes beyond UAT and unit to focus on testing how the database is changing. "Transition Testing" is a major part of the course.

This involves a new way of thinking about how databases are expressed: You want to design and develop based on transitions in the database.

About the Boot Camp

In this podcast, Max gives a quick overview of the TDD Database Boot Camp. Its goals are:

Teach the principles of database agility
Teach technologies that facilitate this approach. We help the team create the environment they will require including:
- Test suites, transition tests
- DataConstructor. Every team receives a 10 user license for DataConstructor, a tool by Hexagon Software. This tool works with NUnit, JUnit, TFS, etc to implement the suites of tests focused on transitions (see Features of DataConstructor). It makes it possible to have live data version control.
Focus on problems that the team is facing now

The boot camp is designed to be an on-site course so that conversations can be confidential and frank, (which is required with database work). It is best if the whole team takes the course - developers, QA, Scrum Master.

Recommendations - Online Resources

Scott Ambler's website: www.agiledata.org
Max Guernsey's Rethinking Agility in Databases
DataConstructor, a tool by Hexagon Software

Recommendations - Training by Net Objectives

Music used in this podcast

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Present and the Possible in Software Development

jim.trott@netobjectives.com (Jim Trott) — Tue, 23 Sep 2008 19:11:36 +0000

The Present and the Possible

There is a gap between what is possible and what is present - what is done - in the software industry. How much time and effort is wasted, how much re-inventing and re-discovery is done because we don't always understand the hard won insights from the past about what is required to create quality, sustainable product? How many companies have not realized the success of process improvements, like Agile, because they have not really understood its principles?

This gap, and the pain and waste it causes, is frustrating. Closing the gap involves a little re-orientation, becoming intentional to learn and try and adjust, to improve continually. To become more professional.

Professionals strive to build on the learnings of others. They avoid taking unnecessary shortcuts, especially when that could harm the product over the long term (imagine what would happen to the civil engineer who kludges together something for the last 2 feet of a bridge just to get it finished up or just to try some new, cool idea). They follow the best practices in how we develop and manage people, in the processes and methods we use, and in the proper way to use tools and technologies.

Laws of the Wood

Professional carpenters know that there are certain "laws of the wood" that they must follow in order to build products that will endure and to build them efficiently and profitably. For example, cross-cutting across the grain give you one kind of cut and cutting with the grain is very different. They are basic laws or principles that must be followed to avoid wasted effort, wasted wood, designs that fail.

We have our own "Laws of the Wood." For example, there are design principles such as the Dependency Inversion Principle, the Open-Closed Principle, the Liskov Substitution Principle (all things that we have written about in Design Patterns Explained). Failing to work within these laws, principles, forces, leads to wasted effort, products that cannot be maintained, designs that fail.

Bob Martin has been advocating this for a long time, calling software developers to become "craftsmen." While Alan uses the term "professional" to describe this, he is in "violent agreement" with Bob and his intent.

It is time for us to raise the bar in terms of how we are building software.

But what about creativity? We don't like to be constrained as developers. Far from taking away creativity, cooperating with these laws and principles allows creativity to flourish. It helps reduce the complexity in what is surely one of the most complex of human endeavors so that what we do create has the greatest chance of succeeding. In the 1960's, NASA put a man on the moon. They cooperated with their "laws of the wood" (e.g. gravity) to create solutions to an amazing array of problems to create a thing of beauty. The laws give us parameters and boundaries within which to be innovative and get problems solved.

If you don't follow the laws, principles, you just won't be as effective.

The Long Journey

Why don't people follow the laws of development?

They don't understand the implications of not following the laws...
They feel time pressures: feel a need for a short cut now.
They fall back into old habits,

Sadly, these short cuts don't always give longer term gain... and if they understood the principles better, the good practices approach is just as efficient as those "short cuts."

It is natural. And change is going to involve taking what Gemba Panta Rei and Toyota calls the "long path".

What this means is that we adopt a mindset to make progressive improvement, learning as we go and adjusting our thinking as we discover what does or does not work. Constantly, intentionally perfecting what we do, sometimes in small steps that take us down the right path.

The good news is that, at some level, many developers do know - or almost know - many of these good practices. They may be buried in our intuition, but at least they are not foreign to us. Sometimes, it is just a matter of surfacing these so that we are conscious about them. And that helps shift our thinking.

The long path involves shifting our thinking at all levels: as individuals, as teams, and organizationally.

The further along we go, the closer we are going to get.The higher we are going to raise the bar on our work. The more satisfying our work will become. The more our customers will realize value from the work we do.

Recommendations - Online Resources

Gemba Panta Rei blog

Recommendations - Training by Net Objectives

Design Patterns for Agile Developers

Music used in this podcast

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Avoiding Over- and Under-Design in Agile Projects (Webinar)

jim.trott@netobjectives.com (Jim Trott) — Wed, 20 Aug 2008 16:40:54 +0000

Avoiding Over- and Under-Design in Agile Projects (audio of the webinar)

A webinar on August 18, 2008 presented by Alan Shalloway focuses on what developers must attend to when building systems with Agile methods. It discusses an alternative to the choices of:

Design for the future which often results in overdesign
Not designing at all which often makes code difficult to change

The mantra of the talk is “minimizing complexity and rework” and shows how to use the advice from Design Patterns, coupled with the attitude of not building what you don’t need from Agile. The talk is basically a compendium of the essential ideas Net Objectives believes that developers need to understand after learning the basics of Scrum or Agile process. At the end of the day, you are still writing code. This webinar is a first start in what you need to know in writing code in an Agile environment.
Attendees will learn:

How Design Patterns give an alternative design approach to the common approaches of over and under design
How decoupling modules from the start can often be done in a simple manner without requiring pre-cognitive abilities
How the understanding of components written by one group and used by another can be defined better

The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

Author:

Jim Trott

Blog Type:

Podcast

Managing Requirements in Agile Projects with Scrum Sharp (Webinar)

jim.trott@netobjectives.com (Jim Trott) — Wed, 20 Aug 2008 16:33:41 +0000

Managing Requirements in Agile Projects with Scrum Sharp (audio of the webinar)

A webinar on August 18, 2008 presented by Alan Shalloway discusses how Scrum#'s enterprise and product focus improves on the standard method of managing with Epics and User Stories. By stepping back to include product portfolio management, Scrum# facilitates working on the right product features across the enterprise, not just working on the right stories in a project. Topics discussed include:

Product Portfolio Management with Minimum Marketable Features (MMF)
How MMFs are more useful than Epics
Going beyond user stories
Managing stories from business value
Handling time and team dependencies in your Sprint backlog

The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

Author:

Jim Trott

Blog Type:

Podcast

Lean-Agile in Tough Times

jim.trott@netobjectives.com (Jim Trott) — Tue, 29 Jul 2008 01:11:40 +0000

Lean-Agile in Tough Times

In times of economic slowdown, you have many choices to make about how to allocate scarce time and people and money. Is it at all relevant to invest in Lean-Agile software development? Why? What would you say? Alan Shalloway believes it is more important than ever. And it is why he places so much emphasis on Lean for those who need to become more Agile.

Focusing on local team efficiency is good... teams become more able to create product with a minimum of wasted effort. But the more important objective - and even more so now - has to be ensuring that the organization is delivering true value to customers as quickly as possible. This requires the entire stream of product creation to working effectively.

The goal is not really to speed up software development. The goal is to speed up delivery of software that customers can use. To be faster now and faster in the future. Perhaps you would call this Enterprise Agility.

I ask Alan to comment on this and on a couple of related questions:

In tough times, is it best to start with small pilot projects? Opinions are mixed.
Where do assessments fit in the improvement mix?
What lessons can we draw from successes and failures that we have seen in the transition to lean-agile?

Recommendations - Online Resources

The TOWS Matrix - Going beyond SWOT Analysis (MindTools)

Recommendations - Training by Net Objectives

Lean Software Development for Management

Music used in this podcast

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Scaling Scrum to the Enterprise with Lean Software Development (Webinar)

jim.trott@netobjectives.com (Jim Trott) — Sat, 26 Jul 2008 20:51:51 +0000

Scaling Scrum to the Enterprise with Lean Software Development (audio of the webinar)

Scrum# is an extension to Scrum that was developed by Net Objectives to solve challenges that were being encountered by many teams adopting Scrum. Read about more about the issues which Scrum# was created to solve. A webinar on July 21, 2008 presented by Alan Shalloway presents a broad stroke of Scrum#. It gives a high view of the process and analysis extensions of Scrum#.

The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

The ideas and strategies introduced in this webinar are also being explored in a book which is currently being written by Alan Shalloway, Jim Trott with contributions from other Net Objectives consultants. Learn more about the book and read selected chapters.

Author:

Jim Trott

Blog Type:

Podcast

Coming Up at Agile 2008

jim.trott@netobjectives.com (Jim Trott) — Sat, 26 Jul 2008 01:23:28 +0000

Coming Up at Agile 2008

Once again, Net Objectives is a co-sponsor of the Agile 2008 conference. This is a premier gathering for people and organizations involved in Agile software development. This year, it is being held in Toronto, Canada, August 4-8. Every year, we devote a podcast to what Net Objectives is doing at Agile 2008, both to help people who are going know what we are up to and to help people who cannot go know what trends we see that are important, where we will be devoting energy.

In this show, Alan Shalloway covers five primary topics:

Why we are involved with the Agile conferences and why they are important for the industry
The Certification by Net Objectives program, which was announced at Agile 2007, including: Scrum Master Certification, Scrum Team Member Certification, and Product Owner Certification
The announcement of the Implementing Agile Development using Microsoft Visual Studio process template, which has just been completed by Net Objectives
An announcement of Scrum#, which is an extension of Scrum that helps to integrate Lean thinking, Scrum/Agile practices, and Emergent Design practices (patterns and test-driven development).
The Talks that Net Objectives will be giving at Agile 2008

The Net Objectives Talks at Agile 2008 include:

Introduction to Lean software Development by Alan Shalloway
Distributed Teams by Ken Pugh
A Half Day workshop on Value Stream Mapping by Alan Shalloway
Two Open Spaces every day, facilitated by Guy Beaver, Ken Pugh, and Alan Shalloway

Recommendations - Training by Net Objectives

Recommendations - Webinar Series by Net Objectives

Three-part webinar series on Scrum#

Music used in this podcast

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Test-Driven Development and Design Patterns

jim.trott@netobjectives.com (Jim Trott) — Thu, 12 Jun 2008 06:00:00 +0000

Test-Driven Development and Design Patterns

Last month, in my conversation with Scott Bain on Impediments to TDD, I wanted to explore how he was incorporating TDD and Design Patterns, two areas of particular expertise for Scott. That is the topic of today's conversation.

Scott has been thinking deeply about patterns for many years and his perspective on TDD and patterns are based on the special insights he has developed - insights that are covered in the Design Patterns Explained course he teaches. What he says goes well beyond the normal way in which patterns are described. As you will hear, we came up with some delightful surprises during our talk together

Embracing Change

In this conversation, we cover how TDD is like design patterns. Both deal with change, something that is always with us in product development. Our natural tendency is to want to resist change because change usually causes us pain. TDD and patterns both help remove the "sting" of change. But beyond that, it becomes something that we can even embrace as a good thing, something that can work to our advantage. Working together, TDD and patterns form a virtuous feedback loop, each reinforcing the other. This is the sweet spot for patterns and TDD.

Evaluating Designs and Testing Strategies

Going deeper, Scott explores how testability becomes an essential factor in evaluating design alternatives. Like Occam's Razor, when you have competing design alternatives, choose the one that is more testable. This is especially important when you are working from a TDD perspective. Well, if you are working from a patterns perspective, you will naturally have highly testable designs: highly cohesive, minimally coupled, focused on just one thing. That is just what patterns do.

Take this deeper. Each pattern is focused on resolving certain forces; it has certain structures and characteristics that are more important. By focusing on testing these characteristics, you have the head start on what would be the most effective testing strategy to use.

And this is a cool insight that could be very powerful for our industry. What if testing became part of how we talk about patterns, became yet another essential characteristic of the pattern? Would that free us up from reinventing testing strategies for what are commonly occurring situations? Wouldn't this further our knowledge transfer about what is an essential need? Wouldn't it give us a good language to use?

Even more, testing approaches, such as mock objects, dependency injection, shunts, can be expressed as patterns. "Testing patterns" become a whole new class of patterns that professional software developers can use, discuss, refine. To this end, Scott has entered the first testing pattern, a Mock Object Pattern, into the Pattern Repository at http://www.netobjectives.com/PatternRepository/ and invites your insights, comments, and additions.

How to Learn this Way of Thinking with Patterns and Testing

This is affecting the way Scott teaches Design Patterns Explained and Test-Driven Development, but not in the way I would have thought. DPE is very focused on helping people understand what patterns are. There is usually a lot of unlearning/re-learning that has to take place. This means that the course is almost entirely consumed by the pattern-specific training. The same is true for the TDD course. The Emergent Design book that is out now and the course that will be coming will serve as the bridge between them, talking about how they interact, how this allows for evolutionary design.

If you want to get good at this, is it better to start with TDD or with DPE, given that you really should know both? In Scott's opinion, it is best to start with DPE because it gives you the essential thinking framework that then equips you for the practical TDD instruction. What seems to work best is to take them with just a one week gap in between. In his experience, this makes for a solid performer on the back ednd.

Scott is an excellent speaker. I get so much out of talking with him and I think you will enjoy listening to him.

Recommendations - Training by Net Objectives

Design, Testing and Programming

Recommendations - Reading and Resources

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Emergent Design: The Evolutionary Nature of Professional Software Development (webinar)

jim.trott@netobjectives.com (Jim Trott) — Fri, 23 May 2008 23:58:24 +0000

Emergent Design (audio of the webinar)

What is design? An opportunity to mitigate risk. A way to look for eliminating waste. It is certainly not simply the "thinking" part of software development.

When are you doing design? Just up front?

When do you test your design?

How much design is enough?

How can design be done in a more natural, evolutionary way and, at the same time, more professional?

These and other questions are pondered by Scott Bain in a webinar on Emergent Design, presented May 22, 2008 . The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is 64 minutes long, so the files are large.

This webinar is based on Scott's book, Emergent Design: The Evolutionary Nature of Professional Software Development, published by Addison-Wesley, 2008.

Author:

Jim Trott

Blog Type:

Podcast

Overcoming Impediments to Test-Driven Development

jim.trott@netobjectives.com (Jim Trott) — Mon, 12 May 2008 20:57:54 +0000

Overcoming Impediments to Test-Driven Development

Recently, I had the chance to sit down with Scott Bain, author of Emergent Design and an expert in Test-Driven Development. He wanted to talk about what he has seen as impediments to implementing Test-Driven Development: impediments that arise before an organization decides to adopt TDD and impediments that arise after adopting TDD. He bases this on his conversations with clients who are in the midst of implementing TDD, on his coaching experience, and on own personal journey with TDD has he has incorporated the concepts into Net Objectives training in Design Patterns, TDD, and Analysis.

Impediments before adoption

Before organizations decide to adopt test-driven development, they usually have to address one or more of these challenges:

Developers will be doing double work and be less productive
Developers know their code too well and cannot write tests well
Testing before coding seems nonsensical

Impediments after adoption

The impediments do not stop after TDD has been adopted. What we see is that after Iteration 3, the TDD effort begins to collapse. It takes too long, the tests are difficult to change, or it is hard to keep up with multiple tests

Overcoming these Impediments

The answers to both of these impediments lies in gaining a new, essential insight: in TDD, the entities we write not not actually tests. They are specifications. What we are doing is replacing traditional specs with automated specs.

The process of writing the specification is an analysis task, one that leaves behind a suite of tests as a side-effect artifact; thus, it is not double work.

TDD does not replace Quality Assurance. They will not be sufficient for all testing.

TDD is another fundamental skill that developers, especially Agile developers, must have. It is something that they can learn when they receive proper training.

Recommendations - Training by Net Objectives

Design, Testing and Programming

Recommendations - Reading and Resources

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Scott Bain

Blog Type:

Podcast

Post-Agile Scrum: The Need for Lean Software Development (webinar)

jim.trott@netobjectives.com (Jim Trott) — Fri, 14 Mar 2008 18:30:42 +0000

Post-Agile Scrum (audio of the webinar)

The Agile Manifesto and the Agile movement have ushered in a new way of developing software. Today, many practitioners are discovering limitations to the usual approach to Agile which focuses mostly on local teams and projects. This limited focus developed as a reaction to heavy processes and teams' inability to make their own commitments. This resulted in many leading Agile practitioners to advocate an approach to "let the team figure it out," going so far as to state that the beauty of the Agile approach (such as Scrum) is that it avoids any kind of prescriptive formula. Yes, prescriptive formulas can be dangerous; however, having a set of principles to guide Agile practices can be extremely useful. Moreover, incorporating Lean management practices are critical for extending the capabilities of an organization using Agile methods.

Today, what is required is helping the entire enterprise become Agile. What is an Agile enterprise? An enterprise that can respond quickly to customer, environment and internal changes to create a competitive advantage. This requires much more than merely trying to apply practices that work for local teams to the entire enterprise - that approach is too simplistic. This Agile Enterprise-perspective is one of the biggest differences between current Agile practitioners and those going beyond Scrum.

These and other questions are pondered by Alan Shalloway in a webinar on Post-Agile Scrum, presented January 24, 2008. The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However,

you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Caution: This webinar is 61 minutes long, so the files are large

Author:

alshall

Blog Type:

Podcast

Emergent Design: The Evolutionary Nature of Professional Software Development (webinar)

jim.trott@netobjectives.com (Jim Trott) — Fri, 14 Dec 2007 02:38:33 +0000

Emergent Design (audio of the webinar)

What is design? An opportunity to mitigate risk. A way to look for eliminating waste. It is certainly not simply the "thinking" part of software development.

When are you doing design? Just up front?

When do you test your design?

How much design is enough?

How can design be done in a more natural, evolutionary way and, at the same time, more professional?

These and other questions are pondered by Scott Bain in a webinar on Emergent Design, presented December 11, 2007 . The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is 58 minutes long, so the files are large.

This webinar is based on Scott's book, Emergent Design: The Evolutionary Nature of Professional Software Development, published by Addison-Wesley, 2008.

Author:

Scott Bain

Blog Type:

Podcast

Enterprise Agility

jim.trott@netobjectives.com (Jim Trott) — Fri, 12 Oct 2007 20:53:27 +0000

Enterprise Agility

Often, organizations invite us in to help them think about how to bring Agile into their development practices. The initial focus is often at the local team level. Our experience is that this is not the best place to start. Instead, we prefer to look for pain points that the organization is feeling in their development work, and we talk with local teams to get indicators of these points.

What is stopping you from delivering the value to customers that you feel you should?
What opportunities do you see and what waste is there?

We can predict some of the answers depending on whether it is an IT organization or a product organization. IT organizations tend to have people working on more than one project at a time whereas in product organizations, people usually focus on one project. This means that IT organizations often have less connection to the business and have more contention for resources. These are all opportunities for improvement that may or may not involve changes at the local team level.

Enterprise Agility, Systems Thinking

“Enterprise Agility” focuses on helping the overall development organization be more able to respond to the needs of the business. It starts by looking at what needs to be done and then on how to do it. Probably, this will involve Agile at the local team level, but that might not be the best place to start.

There is a maxim that “Good people in bad systems still cannot produce.” It is always best to take a systems-view of process improvement, to focus on the systems that people work in. Otherwise, you can end up with sub-optimization – one part of the system doing well but overall, it still under-performs. Doing what is best for the enterprise involves optimizing the whole.

Too often, consultants want to start at the local team level just out of habit. Then, they try to “scale up Scrum to the enterprise.” Beyond the problem with sub-optimization, there is a great danger that you may never even be given the chance to start. Why? If upper management has not already bought into the idea of Agile, then one failed experiment in Scrum can leave a permanent bad impression. Starting with a focus on the challenges of the enterprise – reducing waste and delay, improvements in the value stream – helps them see what they will be getting out of it. An experiment with a local team, then, becomes one of several things you could be trying as a start.

Look for the Pain Points

Chances are that the size of the organization will impact the issues we address, but that is not certain. Rather, it is complexity of process and connections between teams and organizational culture that leads to waste and inability to work with the business. For example, stove-piping, over-burdening processes, a disconnect between business and IT. What are the underlying lean principles that are being followed and what are being violated. The biggest challenge is that pain-points are not always recognized and we tend to think that it is just the way things have to be… that things cannot be improved.

Do the SIPOC

When it comes to analyzing where to start in helping a development organization, it often makes sense to talk to the Business, which is the customer of the dev group, as well as upstream to the Operations, which supplies the dev group. A standard lean technique is to do a simple SIPOC (Supplier-Input-Process-Output-Customer) to be explicit about who and how the organization interacts with the system. All too often, this simple step is forgotten as we are focused on building product.

For example, a local team might already be reasonably productive, even without Scrum. But they are thrashing because their Business customer is not ready to work with them when they need answers. Or the change management system takes weeks to schedule a user acceptance test. These are structural issues dealing with upstream inputs and downstream outputs over which the local team has no control. Attack these root causes of thrashing and you improve the flow. Only then will it make a difference to improve the team.

Enjoy the show!

Recommendations

Web

Challenging Why (Not If) Scrum Works by Alan Shalloway - in Agile Journal or original blog entry

Books

Creating a Lean Culture: Tools to Sustain Lean Conversions by David Mann
The Leader's Handbook: Making Things Happen, Getting Things Done by Peter R. Scholtes

Training by Net Objectives

Lean Training Courses

Music used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I’d encourage you to subscribe to his feed.

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Announcing Scrum Certification by Net Objectives

jim.trott@netobjectives.com (Jim Trott) — Mon, 13 Aug 2007 08:00:00 +0000

Announcing Scrum Certification by Net Objectives

Scrum Certification by Net Objectives is a new program by Net Objectives to help the industry and especially our clients have a reliable, repeatable, and meaningful process by which to assess the competency of individuals and teams to be on a Scrum Team, to be a Scrum Master, or to be a Product Owner. This podcast announces the program and the motivations behind it, including the following:

What this program is and what it covers
The motivation behind this program
Why the industry needs certification in Scrum
What we mean by “certification”
What certification will involve
When it will be ready

The need for this is borne out of our experience having trained almost 20,000 people in Scrum and working with many major corporations rolling out Scrum, what people need to get proficient with Scrum.

From my own vantage point, it seems like time to do this. Other improvement initiatives, such as Six Sigma, Lean Manufacturing, and ITIL have meaningful certification programs based on observed best practices and defined competencies. Standards-based and open to improvement. It provides the objective foundation for a conversation by the profession in what it means to be a competent worker, mentor, or master trainer. And it provides a roadmap for people who want to progress.

This program is ready now. If you want to get more information, you can call 1.888.LEAN.AGILE or read the press release at www.netobjectives.com/news/20070813-press-release-scrum-certification

This is sure to be talked about and I welcome your thoughts. Drop me a line jim.trott@netobjectives.com

Enjoy the show!

Recommendations - Training by Net Objectives

Scrum Training Courses

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Lean-Agile and the Process-Innovation Pendulum

jim.trott@netobjectives.com (Jim Trott) — Mon, 30 Jul 2007 06:00:00 +0000

Lean-Agile and the Process-Innovation Pendulum

Alan was the keynote speaker at the SQE Better Software Conference in Las Vegas this year. Conferences are great for stirring up ideas and generating insights. For this podcast, I wanted to continue the series on Lean Anti-Patterns, sharing some more from what we are learning as we write this book. But you cannot always control a conversation. One of the hardest things to know as a facilitator is when to re-focus an individual or a group and when to let the ideas flow. You want the ideas to emerge and you want them to create the result. Today, I went with the passion, letting him share because I knew we’d get back to the other topic another day.

Innovation or Process?

Maybe it is a little like the challenge of the software industry: do we want process or do we want innovation? We keep shifting between the two. Software development methodology seems move between being creative and processes to control chaos. In the 70's, we had waterfall methods to structure our work. The 80's saw a burst of creativity with the rise of the PC, thousands of developers coming in and process took a back seat. The 90's saw a tension between the Internet (creative) and CMM (process). And where are we now?

Maybe it is time for a happy medium. Maybe lean can help us achieve it.

Lean sees process is the structure in which creativity can be expressed. Having standard work process frees me from having to think about the routine stuff so that I can spend creative energy on new stuff. The routine stuff always has to be done; standard work organizes it so that I do not have to devote more energy than necessary doing it.
I do not have to decide if I am going to do testing, if I am going to have work-cell teams, if I am going to communicate with customers. That is the routine.

As an example, I have just finished working with an organization where we needed to upgrade our Microsoft Office software. Now, you would think that ordering software would be fairly routine since the funds were already in place. But they had no process! Without process, it became an ordeal, all dependent on one guy to be a hero and figure out what to do next. We could go only as fast as he could work. Three weeks later, we are almost there. How much of his effort – and our time – was wasted because they had no process for the routine stuff.

Scrum and Iterative Analysis

Our biggest challenge is, and continues to be, to build products the customer wants. Thus, the biggest risk is building things the customer does not want. How do you manage this in a more complete way?

Lean-Agile would say to do a little, learn a little, then adjust based on customer feedback. Do not do workarounds and do not build too much. Seen this way, Scrum is perhaps more of an iterative analysis technique than an iterative development technique. It helps to minimize that risk of building what the customer does not want. The rest of the Lean-Agile framework – Analysis, Design Patterns, Test-Driven Development, Scrum, Process, QA – certainly help us to have an environment where this can be done.

Lean-Agile says it is OK to be productive, even without Scrum

That sounds flip, but it is a key point. We have had a number of clients where one of their groups is clearly more productive than the others. Yet none of them are doing Scrum, none of them are using iterative development. What accounts for the better performance? They are using Lean-based principles in their routine process while the others are not. They have co-location, voice of the customer, more up-front testing. And they are being productive.

Here is a story. One friend, a development manager at a software company, told me that he is ready to kick off his teams people who are Scrum evangelists. They do not recognize that he is applying the principles already in ways that fit their situation and they are greatly more productive than others. Other Scrum practices just don’t fit their needs. Rather than rebuking them, Lean-Agile would praise them while encouraging them not to be satisfied. He could live with that.

This is key because the goal is not to do Scrum. The goal is to produce more software that our customers see as valuable and less of what they do not want. Don't be dogmatic.

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Music used in this podcast is by Kevin McLeod: http://www.incompetech.com. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I’d encourage you to subscribe to his feed.

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Lean Anti-Patterns: Overview

jim.trott@netobjectives.com (Jim Trott) — Tue, 12 Jun 2007 21:40:32 +0000

Lean Anti-Patterns: Overview

It doesn’t have to be this way. Haven’t you felt that in your tummy sometimes? You and your team end up doing the same thing again and again, and you just get the same results again and again. And here you are again, starting out on that familiar path and it is going to be painful again. Around and around. That is an “anti-pattern”: Repeated patterns of work and behavior that produce counterproductive results.

Alan Shalloway has been training companies across the country in lean for software development.

As he has been working with clients to help them implement lean, he has heard many of these similar stories and problems. After hearing some symptoms, he can often identify more fundamental, root issues because he has built up a mental library of these anti-patterns. Giving names to the problems, Alan and his clients discover they can delve into solutions more quickly.

Alan has come to see the study of anti-patterns as very important for learning lean. In the West, people can usually identify what is going wrong much more quickly than they can see what to do right. Anti-patterns gives you the ability to discuss the “what’s wrong” without dropping into whining or complaining. They also give a common discussion point around why the lean principles are so important: when you violate the principle, this is what happens. Together, this helps management understand what needs to change and why it is important.

Based on this, Alan and I have begun to write a book called Lean Anti-Patterns and what to do about them. This book has six or seven parts and future podcasts will cover each of these parts.

A quick overview of lean. There are a lot of great books, so this will be fast. Poppendieck. Womack and Jones. Liker. Fast-flexible-flow. How to get ideas in and get product out. How to deliver fast. Integrating the notions.
Lean Anti-Patterns. Anti-pattern that violates lean principles is a lean anti-pattern. What is the principle that it violates and why that is a problem
Anti-patterns in management. Patterns that are structural, process, customer-focused, the stuff that management must deal with all the time. This podcast will focus on one in particular: having too many projects.
Technical anti-patterns. Not problems in coding, but but anti-patterns that occur in the technical team. Example: Delays in coding.
Things that result from the anti-pattern. This discusses the symptoms that you likely to see when there is an anti-pattern. Tempting to think these are causative, but usually they are signs of deeper issues. Example is thrashing. Teams thrash when multi-tasking, get caught up not getting anything done. That is not the cause of the problem; instead, being caused by too many projects. If you keep doing what you keep doing, you are going to keep getting what you keep getting.
Transitioning to lean. Lean is one of things that are simple but not easy. Find an easy gain to have. Little deeper. How keep it going. Book recommendations. What is the high level roadmap?

Anti-patterns help management and workers work together to see beyond the current state to see what can change. No longer victims.

In Addition

Alan is working on two other projects that support this book effort.

Webinars. First, he is developing a series of webinars that will take a deeper cut into the topic.
Online. Second, he is developing a series of online learning opportunities. The nature of lean requires learning a lot. A 2-3 day intensive course is good for teams, but maybe for individuals, it is more effective to do this over time, giving you time to think.
If you are interested in this book or these trainings, send note to Alan at alshall@netobjectives.com

Personal Note

On a personal note: Today, I am wishing a happy 25th wedding anniversary to my lovely bride! Amazing, still!

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Music used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I'd encourage you to subscribe to his feed.

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Completing the Agile Development Puzzle

jim.trott@netobjectives.com (Jim Trott) — Wed, 09 May 2007 06:00:00 +0000

Completing the Agile Development Puzzle

Bob Hartman is Net Objectives’ Vice President of Business Development and Marketing. He has over 20 years experience in the software industry and has seen it all. Maybe it is all those years in the trenches or maybe it is the gray in his beard or maybe it is living in Colorado, but I find his perspectives to be refreshing. He sees what organizations truly need and does a great job helping them.

Recently, I had the chance to talk with Bob just after he gave a free public seminar called How to use lean principles to complete the Agile development puzzle

This seminar was motivated by Bob's keen awareness that Agile – as it is usually taught – is not nearly as effective for teams and organizations as it should be. Teams only go so far and are left to struggle with how to improve, or must hire expensive consultants. Lean helps complete the picture.

Here's a little more detail.

To paraphrase a familiar quote, “Give a team Agile and they can work effectively until it breaks. Teach them Lean principles and they can continuously improve.” Clearly, he’s a recovering geek. But it is still true.

The thrust of his seminar was to help people understand the lean principles that provide the foundation for Agile, so that they can be freed from the “Agile recipe book” to know how to adapt processes for themselves. They need to know the “Why” behind the “What.”

Repeatedly, Bob has helped organizations compare the Agile practices they are doing now – especially what is not working as they had hoped – with the lean principles that inform those Agile practices to help them see where they need to go. Then, they can develop plans to get there. Knowing the principles gives Bob the “power” to see gaps.

Here are some examples of problems that we see time and again in Agile teams.

Agile problem: Testing happens at the end of an iteration.

What usually happens: The Agile team runs out of time, so they push testing off to the next iteration.
And then they push more testing off to the next iteration. And so on, always building up “testing debt.” Testing early is not a typical Agile process.
Lean principle being violated: “Build Quality In.”
Lean teaches another perspective on testing – it is essential right from the start. The goal is not simply to uncover defects but to prevent them in the first place. We want to build quality in, not test it in. Otherwise, just doing risk management. But building quality in (using TDD and acceptance tests up front), the team knows that the product is defect free.

Agile problem: Trying to do more than in the current iteration than you had in the previous iteration.

What usually happens: A team is pushed to go faster or get more done in the next iteration than they had done in the past iteration.
The work piles on. And teams think there is something wrong with them or that the last iteration was just an aberration.
Lean Principle: “Respect People” and “Do not multitask” and “Deliver Fast.”
Teams usually don’t go faster than they have done. It is better to let them go at their established, sustainable pace, using disciplines rather than heroics. If they get their work done, they can always pull more off of the backlog, but should not be pushing stuff off. Piling on more work comes from fear that the team is not performing adequately, not going to get all of the features finished. But it is better to deliver whole features earlier to customers than to wait and wait and deliver a set of features late – the customer gets more value earlier

Agile seems to be focused on improving teams. This is good, but may be sub-optimal. Teams end up focusing on their piece of the overall effort. Lean thinking builds on this to say, “let’s look at the entire stream of work we do, from the initial concept to cash in the door.” It helps management see their part in orchestrating something that will optimize the entire flow.

For example, suppose you have a team that can turn a requirement into a finished product instantly. A wave of the wand and a perfect product is created. They would be really impressed with themselves. But then, suppose it takes shipping 6 months to get it to the customer and it takes billing another 9 months before the purchase order is sent and product support does not get the support manuals for 15 months. Now, it appears that neither the customer nor the business is getting much value from that instant product. There is lots of room for improvement.

Lean gives the eyes to improve the entire value stream.

That is why we teach Lean and Agile and Test-Driven Development and Patterns in an integrated way. They all work together. And the people doing the work also work in an integrated way.

That is why we believe in offering Implementing Scrum for Your Team as something for whole teams – business and technical – rather than sending people one at a time. Integrating people from the get go is the most effective path to success.

Enjoy the show!

Talk to us

I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you.

Recommendations - Training by Net Objectives

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Know Thy Audience - Part 2

jim.trott@netobjectives.com (Jim Trott) — Sat, 05 May 2007 06:00:00 +0000

Know Thy Audience - Part 2

Happy Cinco de Mayo 2007!

I will be doing a couple of shows with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. He is a gifted coach who connects with senior management as good as anyone I have seen. He knows how to get things moving.

One of the critical success factors for introducing Lean-Agile software development into an organization is to be prepared. To understand who you are going to be working with. This is the first discipline you need to adopt to become a good Lean-Agile coach. Prepare and then prepare to be a learner (your first impressions are almost always wrong or at least incomplete).

This show continues the conversation on preparation that we have been having with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. I am highlighting him to you because I find him to be a gifted coach who connects with senior management as well as anyone I have seen. He knows how to get things moving. I learn a lot by watching him and I think you will glean important ideas as well.

You may recall, Alan categorizes clients into Entrepreneurial, Structured, and Highly-Defined organizations. How does this help him? He identifies several ways:

It indicates the approaches to take to help the organization learn this new approach
It gives a sense of their openness to innovation
It helps predict the number of projects and variety of experiences that will be required during the discovery phase before management and workers can feel that this approach will work in their environment.

Here is a little more detail

The benefit of categorization

First, categorization helps develop the approach to take to help the client learn this new way of doing product development. The more formal and specialized their work, the more they may have to unlearn before they can start to learn. The more centralized, the more likely it is that the central group will have to be involved in this “unlearning” early in the process.

Along this line, it gives a sense of how likely the organization is to be able to learn, to improve, and to innovate. A very telling measure is to ask, “How often have practices been revised? And by whom?” The more entrepreneurial, the more likely they will be able to embrace change and empower local improvements.

Categorizing customers indicates the breadth of “experimentation” or discovery that will be required in the consulting engagement. In an entrepreneurial organization, starting with local teams (the normal approach of Agile coaches) can be successful; but in highly-defined organizations, this will probably not be helpful: your sample size is just too small. The local team will often be so specialized that their issues will not be representative of the organization or the project types they face. You will not have demonstrated that the approach will work nor scale to the program level and so you will not get management buy-in.

How will you drive out risks: in teams and in the organization (is Agile sufficient?)

Remember, early in your consulting engagement, you are trying to drive out all of the risks that the client may face. It would be very easy to help local teams become highly productive product development engines. The main risk is just getting teams to adopt to a new way of thinking. If you can get over that, the “gossip network” will become a great ally. Emphasize an Agile approach and you will have good success with the team.

However, simply emphasizing Agile will not lead to long-term success in more highly-defined organizations. The more highly-defined the organization, the more likely it is that the risks will not be evident right away. Local teams may become efficient, but there will still be organizational impediments that get in the way of the larger objective: improving the throughput of value to the customer. Will the team be allowed to work in an Agile way? Will the business be able to adopt to the new way of working closely with the product developers? Will teams be empowered to change processes? This is where lean comes in.

In the more highly-defined organization, your consulting plan must be based on multiple projects and multiple team types to discover the impediments to success.

Do as much planning as necessary to get started… and no more

Alan expects to do as little planning as necessary on the highest priority issues and risks. I will work with the client to decide how we will address or mitigate the issues and risks or whether we will choose not to address them for now. Do enough planning to get started.

And then set the expectation that this will be a continually evolving effort.

Enjoy the show!

Talk to us

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
“On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Know Thy Audience - Part 1

jim.trott@netobjectives.com (Jim Trott) — Tue, 27 Mar 2007 06:00:00 +0000

Know Thy Audience

Dwight Eisenhower said, “Planning is everything, the plan is nothing.” One of the critical success factors for introducing Lean-Agile software development into an organization is to be prepared. To understand who you are going to be working with: their motivations, experiences in development, world view, and their focus in development efforts. Who makes decisions and how are they made? The thought work you put into your planning now will help you create a plan that both helps you focus on the important things first and gives you a flexible framework for the future. The more you engage with the organization, the more you should expect to adjust your coaching plan: it will never be correct the first time out. Adjustment is completely acceptable in Lean-Agile. What is not acceptable is going in unprepared. Lean-Agile is not chaotic. It requires discipline and a framework to build on.

Early in his preparation to talk with a client, Alan spends a fair amount of time trying to understand who he will be talking to, what is driving them when it comes to software development. He classifies them as Entrepreneurial, Structured, or Highly Defined and that helps him decide what he will emphasize first. Of course, this is a tentative classification until he knows more. In this show, Alan discusses his classification approach.

On a personal note, I can hardly believe it has been 2 months since I have done a podcast. It has been a crazy few months for me at Net Objectives. I have been on a couple of client coaching visits, worked with the Information School at the University of Washington (http://ischool.uw.edu/), and helped to develop our new web site, which is based on the Drupal content management system (http://www.drupal.org/).

Drupal is a great tool and should serve as a good foundation for going forward. We had the good fortune to work with Scott McDaniel of Decisive Communications to help us with the new site. He is a WordPress expert who learned Drupal very well.

If you haven’t had a chance to see our new site, take a look: www.netobjectives.com. We have put up a lot of new resources for registered users and customers. Hopefully, you will find it helpful.

All of that and writing two books and learning to be a manager. Well, I am glad for VersionOne (http://www.versionone.com/) to help me manage my work in an agile way and for patience of my friends, family, and listeners. I hope to be on a more regular production track now.

Enjoy the show!

Talk to us

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Recommendations - Technical

Drupal - Open source content management system
Scott McDaniel's site Decisive Communications. He helped us with the design of the new site, www.netobjectives.com

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
“On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Lean and What do we do next? - Part 2

jim.trott@netobjectives.com (Jim Trott) — Sat, 27 Jan 2007 07:00:00 +0000

Lean and "So, what do we do next?" - Part 2

These Lean-Agile principles all seem reasonable, but abstract. What do we do to put it into practice? This is part 2 of a discussion on this.

OK. Root causes, Agile, Value Stream. What else?

I held this interview just after a challenging Lean-Agile Overview class. Midway through, the students seemed restless or frustrated. One of those times where you know you are just not getting through to them, that something is blocking the students’ ability to hear what you have to say. That happens sometimes and when it is a crowd of managers in the room, you know that no amount of pushing through the material is going to help. Taking a cue from the lean thinking principle to “stop the line” when something is going wrong, Alan Shalloway decided that the best thing was to stop the class and see what was going on.

The feeling of relief was tangible. They were only too happy to vent. “We understand these lean concepts: eliminate waste, decrease cycle time, doing just enough, voice of the customer. The concepts make sense. So, tell us, what are we supposed to do?”

What sort of practical advice does lean offer me to start improving our processes? That is the question that every manager has. The principles of lean thinking seem obvious, general, and abstract. Putting them into practice is not so obvious. Help me make the connection.

There are a couple of ways to answer this question. The easy answer would be to hire me as a consultant and do whatever I tell you. But the better answer is to use this as an opportunity to learn lean thinking, to take on the eyes of lean. I wanted the students to learn to think honestly about the root causes that create limits to productivity. To learn to look for delays. And then to start using some simple tools that can help you remove bottlenecks in as smart a way as you can. And finally, to learn not to be afraid of starting where you can to make small improvements every day.

In jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you.

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Recommendations - Reading

Managing Transitions: Making the most of change, by William Bridges
Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck
Lean Software Development by Mary and Tom Poppendieck

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
“On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Lean and What do we do next? - Part 1

jim.trott@netobjectives.com (Jim Trott) — Thu, 18 Jan 2007 07:00:00 +0000

Lean and "So, what do we do next?" - Part 1

These Lean-Agile principles all seem reasonable, but abstract. What do we do to put it into practice?

The problem of thrashing

It has been one of those years this last month. Snow, holidays, and hospitals conspired to put me behind. So I have gotten really far behind and am slowly digging myself out. I suppose you could say to me, “Physician, heal thyself!” because I have gotten caught up in the multi-tasking / thrashing trap that we are going to talk about today. Has that ever happened to you? Where you have so much going on, so many tasks clamoring for your attention that you don’t know where to turn next? I think I am a good multi-tasker, so I was amazed at how behind I got. I decided to adopt the Lean-Agile technique of doing more by doing less at one time. My throughput has improved, even if it means I have not gotten some things – such as the blog and podcast – done according to schedule.

Well, last week was spent working on a new content management system, based on Drupal. It is part of our knowledge management efforts here at Net Objectives. My prototype is done (and I’d be happy to share with you what I learned). We should get back to a weekly schedule on the podcasts soon.

OK. So, what do we do now?

I held this interview just after a challenging Lean-Agile Overview class that Alan had had. Midway through, the students seemed restless or frustrated. One of those times where you know you are just not getting through to them, that something is blocking the students’ ability to hear what you have to say. That happens sometimes and when it is a crowd of managers in the room, you know that no amount of pushing through the material is going to help. Taking a cue from the lean thinking principle to “stop the line” when something is going wrong, Alan Shalloway decided that the best thing was to stop the class and see what was going on.

Think about root causes

Alan’s first answer to the question, “so, what do we do now” is to make the connection between the problems of delay you are seeing and the root causes for those problems. Organizational silos and thrashing are two primary types of root causes for delay. Thrashing is caused by multi-tasking, often brought on by having too many projects going on at once or having projects that are too large and complex.

A “Bold Claim”: Do more by doing less at one time

We see organizational silos and thrashing in one form or another in so many software development groups we talk to. Alan echoes a bold claim made by Mary and Tom Poppendieck that the best way to get out of thrashing, to improve your throughput when your pipeline is overfull is to stop trying to do so much at one time. As an organization and as an individual, you are better off focusing on one (or two) things at once, get them done, and then move on to the next thing. Having fewer projects and smaller projects is the way to avoid thrashing due to multi-tasking. This is an important – if scary – place to start.

Start eliminating delays, wherever you can and all the time

So, where do we start to to eliminate delays?

Alan has two answers for that.

At the team level, begin to introduce Agile development techniques.
At the business level, look at the entire value stream: everything that is done from initially getting customer requirements through to final delivery of finished product and getting feedback and providing support

Where you start probably depends more on what you think you can do at the moment, where your position of influence is. Both can deliver good results. Too often, people start with agile for a development team because that is where the coaches are, rather than thinking about where their bottlenecks are and starting there.

The important thing is that no matter where you start, you have to push on to get Lean-Agile thinking into the entire organization, from the local team level to the value stream management.

That is the third answer: a relentless pursuit of incremental improvements, small and large. Don’t feel like you have to solve everything all at once. Big initiatives rarely work and usually cannot be sustained. It is better to get 1% improvement every day than one 20% improvement that never happens again.

Look at the Value Stream

If you can do it, it is better to start looking at the value stream than to simply implement Agile. Why? Because the development team might not be your main bottleneck. Sure, you might make that team more efficient, but if the process is jugged up elsewhere, the customer won’t really benefit. They will still get the finished result as slowly as ever.

Here is an example:

One of our clients had a great development team. They could turn around requirements fairly rapidly. But not matter how fast they were, how responsive they were, customers were still dissatisfied because of delays in delivery. It seems that installations never went quite as well as planned. It turns out that the marketing department had over-promised on the product configuration. Invariably, the sales engineer was faced with days of work to install the product on yet another non-standard configuration. The delay was not being caused by the developers but by marketing. Looking at the entire process from customer requirement to product installation, they discovered the major queues were no in development but in installation. Doing a root cause analysis led to an understanding that marketing was not evaluating the customer’s infrastructure sufficiently. They changed the marketing process, which led to quicker installs, further up-sell opportunities, and more satisfied customers.

All with no change to the development process.

Talk to us

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Recommendations - Reading

Managing Transitions: Making the most of change, by William Bridges
Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck
Lean Software Development by Mary and Tom Poppendieck

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
“On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Lean and the Reasons for Going Agile - Part 2

jim.trott@netobjectives.com (Jim Trott) — Thu, 07 Dec 2006 07:00:00 +0000

Lean and the Reasons for Going Agile - Part 2

Agile helps development teams get their projects done quickly. It helps to make development teams very much more effective. Lean helps the organization to deliver value to customers quickly while retaining the ability to add value quickly in the future.

This is the bottom-line message of two podcasts that talk about how Lean thinking offers compelling reasons for organizations to think about going Agile. This is based on conversations that Alan Shalloway has been having with customers across the country about this. The five most important reasons are:

Add value to the business quickly
Gaining clarity on customers’ needs
Projects can be managed better
Early feedback makes for motivated teams
Engineer practices favor Agile

In the last podcast, we talked about the first point: adding value to the business quickly. In this show, we cover the other four points. Really, I should have done these four together, but it would have made a show that was just too long. So, be sure to listen to both of them to get the full story.

As you will hear, we are just jumping right into the conversation, so it may feel a little bumpy starting out. I think you will catch on.

Make this series useful for you

As we are dive into the issues of Lean-Agile, we want this series to be really useful to you. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com and let me know the topics you want us to cover. And keep checking our blog site at blogs.netobjectives.com for related information and to subscribe to be kept up to date on the shows.

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Recommendations - Reading

Release It! Design and Deploy Production-Ready Software by Michael Nygard
Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck
Lean Software Development by Mary and Tom Poppendieck

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
“On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Lean and the Reasons for Going Agile - Part 1

jim.trott@netobjectives.com (Jim Trott) — Fri, 01 Dec 2006 07:00:00 +0000

Lean and the Reasons for Going Agile - Part 1

We have been snowed in here in Seattle for the last week. It wasn’t that much snow, relative to Milwaukee, where I spent some of my childhood, but it was enough to disrupt most of our infrastructure. We just are not used to thinking about snow here. How to drive in it, what to do if we get stuck, how to adjust. It took my neighbor almost 8 hours to get from his Microsoft office to home the other night. Just a nightmare.

I took my 16 year old daughter out on the ice to teach her how to drive. She needed to learn a new way of thinking so that she could adapt to the new realities she faced. Her normal thought processes would just land her in a ditch. She needed a coach to help adjust her thinking and time to practice. My hair isn’t too much whiter today, I’m pleased to say.

In the same way, it is increasingly apparent that the older ways we did product development are inadequate. The world feels like it is changing and we need the skills to be flexible and adapt to these new situations. Perhaps it was always thus, but it is even more so now. We have to learn new ways of thinking, not just a new set of tools. Principles inform process and technique.

Lean and Agile are these new ways to think about software product development. Lean provides the compelling reasons for going Agile. These are not often talked about in the Agile community, but are well worth considering to motivate the adoption of Agile. The more you understand the principles of Lean thinking, the more powerfully you can implement the processes of Agile and the tools of Lean.

The bottom-line is that agile helps development teams get their projects done quickly. It helps to make development teams very much more effective. Lean helps the organization to deliver value to customers quickly while retaining the ability to add value quickly in the future.

Alan Shalloway has been talking to customers across the country about this. In this show and the next, Alan and I will consider what he feels are the five most compelling reasons for going Lean-Agile:
• Add value to the business quickly
• Gaining clarity on customers’ needs
• Projects can be managed better
• Early feedback makes for motivated teams
• Engineer practices favor Agile

In this podcast, we talk about the first point, adding value to the business quickly. I confess that I am torn about stopping here because the next points flow rather nicely from this. But, if I didn’t stop, it would be an hour long and that is just too long for this format, I think. So, be sure to listen to this and the next podcast together!

In this podcast, Alan refers to two diagrams in his podcast:

The case for iterative development:

Develop the product mix to maximize what the customer is clear about and do not work on what they must speculate about

Scheduling Note

Over the next several months, Alan and I plan to have a series of discussions to delve into what he is learning and deepen our understanding about why this is so important to people doing product development. He has been teaching the Lean-Agile Overview with major companies across the US and overseas and is bursting with important insights. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them.

These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them.

Make this series useful for you

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Recommendations - Reading

Enterprise Engineering for Developers: Designing Beyond Release 1.0 by Michael Nygard
Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck
Lean Software Development by Mary and Tom Poppendieck

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
“On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Lean-Agile and the Project Manager - Part II

jim.trott@netobjectives.com (Jim Trott) — Tue, 21 Nov 2006 07:00:00 +0000

Lean-Agile and Project Management - Part 2

This show involves two conversations. First, a short discussion about how the need for speed-to-market to stay ahead of younger competition is a fundamental driver for Lean-Agile. Then, we continue the conversation we started last week about Lean-Agile and Project Managers.

In particular, we focus on:

The Project Manager as fundamental partner in optimizing processes (internal and external)
The true responsibilities of the PM (improving what you can influence, not just what you can control)
How PMs reduce waste (How project managers can help to reduce waste: multitasking; getting testing and development to be working more closely; equipping the team with knowledge and skills; improving the processes that support the team)
Getting the team to follow Principle Zero (Principle Zero: There is always a cost to violating a principle, regardless whether it is the right decision to violate the principle; so always stop and count the cost to see if the decision is worth the cost.
Facilitating frequent retrospections
The PM and Metrics

This show introduces Jean McAuliffe, a new senior consultant from Boulder, Colorado who has just joined Net Objectives. She comes with a lot of great experience in Agile processes and tools and is a great addition to the team.

Scheduling Note

These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them.

Make this series useful for you

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Recommendations - Reading

Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck
Lean Software Development by Mary and Tom Poppendieck

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
“On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Lean-Agile and the Project Manager - Part 1

jim.trott@netobjectives.com (Jim Trott) — Fri, 17 Nov 2006 07:00:00 +0000

Lean-Agile and Project Management - Part 1

On Lean-Agile Straight Talk, we have taken a fair amount of time working through the basic dimensions of Lean-Agile product development: Lean Principles, Agile Processes, and Technical Practices. We have talked in general about how we got here and why it is important. We have laid enough foundation and can dive down a bit.

Alan Shalloway has been teaching our Lean-Agile Software Overview course several times a month to companies and public gatherings across the United States and overseas. If you know Alan, you know that every time he does one of these, he gains some new insight, discovers a new implication. He is literally bursting at the seams with lessons and he wants to share them. So, over the next several months, Alan and I plan to have a series of discussions to delve into what he is learning and deepen our understanding about why this is so important to people doing product development.

This podcast is the first of two parts covering Lean-Agile and the project manager. Most companies have project managers to help them bring projects in on schedule and on budget. I have had to deal with a number PMs who tried to win through strong arm tactics and sweet talking and it usually backfires over the long haul.The good PMs seem to be able to be a servant for the team, while asking the hard questions, while making management look good, while helping the team think better. Lean-Agile affirms all of this and adds more. These good PMs will take to Lean-Agile and feel stretched at the same time.

Scheduling Note

These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them.

These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them.Make this series useful for you

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Recommendations - Reading

Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck
Lean Software Development by Mary and Tom Poppendieck

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
“On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Lean-Agile is about Collaboration... Patterns Make it Happen

jim.trott@netobjectives.com (Jim Trott) — Wed, 01 Nov 2006 07:00:00 +0000

Patterns give devs a language for collaboration

Lean-Agile puts a premium on collaboration. We always talk about increasing the bandwidth of communication: between customer and developer, between members of a development team, between your team and other teams, and, indeed, between various generations of a team (why did they do it that way?) Gone are the day of a programmer sitting alone in cubicle; most developers find themselves as part of a team.

Now, it has always been easy for developers to talk about implementation. We have coding structures and algorithms. All very precise and widely understood. But it has been very difficult to talk about design. Sure, we have UML diagrams and specifications and requirements documents. But, they don't really get to the essence of the thought behind a particular design. That is where patterns come in. Patterns give us a language to talk about design ideas.

Each pattern is a shorthand for a bucket of forces and principles and constraints and the costs involved in the pattern. When I say I used a Decorator here, you can know what is expected and we can talk about why it was chosen and the rationale for what went into its particular implementation. We can discuss the tradeoff of this approach vs. that approach based on the pattern's cost. This is how professionals talk to each other.

But not only within a team, patterns allow you to access the knowledge of a larger community of professional developers. If you are working on a particular design and discover part way through, "this looks like a Bridge", then you can turn to the Bridge pattern and see what else it is telling you should be there. It can accelerate your rate of development by predicting the elements that must be in your design.

Now this works as long as you can see a pattern as the shorthand and remove yourself from a particular coding implementation. Too many patterns courses and books dwell too much on the implementation, and you lose the essence of - and thus the real power behind - the pattern.

A central repository of patterns

Now, for patterns to become a useful language, everyone has to have a common understanding of what they are about, what they mean. There is a large number of patterns and they grow as we learn more about them. What is needed is a central repository where we can talk together about the patterns. There are other pattern repositories, but none of them talk about patterns in the way Scott is talking about them: as a language, as a collection of forces and language elements.

All of this has led Scott to create an open repository with this in mind: http://www.netobjectives.com/PatternRepository/. This is a community-based repository, sponsored by Net Objectives. You can read for free. Or if you want to contribute, you can register and become an editor, much like the wikipedia does.

Net Objectives is sponsoring this because it brings value to the community. And that is one of the central tenets of Net Objectives.

Emergent Design

To complement this work, Scott is working on a book about Emergent Design, which covers two points

Designs emerge
The need for developing a professional language

This book is out for review, to good response right now. The book helps get people ready. The repository then grows the community. He is also working on a course on these ideas.

A Podcast Series with Scott Bain

This podcast continues a series of conversations with Scott Bain, a senior consultant and one of the premier experts in patterns and test-driven development. He teaches and coaches three Net Objectives courses: Design Patterns Explained, Advanced Software Design and Test-Driven Development. He has thought deeply about patterns and Lean-Agile.

In this introduction, we cover:

What are design patterns (and what are they not)
Are design patterns still relevant?
Patterns, TDD, and change
Patterns as part of the language of professional developers
Getting an Agile team started in patterns

In the future, I will try to get Scott back to work through an example.

Recommendations - Resources

The Net Objectives Pattern Repository. This repository is sponsored by Net Objectives, a Seattle-based organization dedicated to training, coaching, and consulting on software design, agile methodologies, test-driven development, lean software process, and scrum. You are free to use this material for your edification and study, and, optionally, you may contribute your views on patterns and forces in software development by signing up for a free membership. The site manager is Scott Bain.
For other online resources provided by Net Objectives, please visit Net Objectives Resources area.

Recommendations - Training by Net Objectives

Recommendations - Reading

Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
“On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Embrace Change through Patterns and Test

jim.trott@netobjectives.com (Jim Trott) — Thu, 26 Oct 2006 06:00:00 +0000

Embrace Change through Patterns

Perhaps one of the benefits of Agile is that you can get frequent, almost constant validation of what we are doing. In waterfall approaches, it too often happens that after a Plan-Do-Review cycle, the review results in bad news: something is wrong. Now, we have to go back and re-work a bunch of stuff. That is wasted effort.

In Lean-Agile, we try for more frequent and early approvals. We recognize that developers almost never get it perfect the first or second (or third) time through. We recognize that the Business needs to change the system to respond to current conditions or as they learn more about what they need.

We want to embrace change, but it comes with a cost. Lots and lots of change can be demoralizing if it causes a lot of re-work all the time. How can you embrace change without overwhelming the team?

Patterns and Test-Driven Development address this issue. They are based on the premise of the Open-Closed Principle, which implies that if change is a problem for you, then change the rules.

Patterns guide you to set up your environment so that, when change comes, you can accommodate it by adding something new rather than having to re-work something old. The impact on the overall system is much less.
TDD helps you work in very small increments, allowing you to defer commitments to one design choice or another while you are still learning about your system. Make your commitments when you are smart, not when you are still ignorant.

Together, they make change much less expensive and much easier to accommodate change. This is critical to Lean-Agile where we are trying to embrace, rather than prevent, change, as we try to create products that track with what customers truly want, and as we learn together what we want to do.

How do patterns do this? Due to Open-Closed, they encapsulate variation, which means that you can contain the variation happening to your system. Containment reduces the overall impact. Each pattern addresses a different type of variation, each pattern allows me to be open-closed about some type of variation. For example,

The Strategy Pattern encapsulates the variation of a single algorithm. If I get a new version of that algorithm, then I can introduce that variation without having to change the system. The Strategy Pattern hid the algorithm in an abstraction.

The Decorator Pattern allows you add many behaviors on top of a base behavior (for example, think about filters on a camera). Decorator allows you to hide, or encapsulate, or be Open-Closed to the types and number and order of these behavior.

Creational patterns allow you to encapsulate the ways in which objects are instantiated, allowing for changes in the future to the way you create objects.

What is interesting is that this way of thinking about Patterns is not really in the Gang of Four book. But it is crucial to understand if you want to do Lean-Agile in a sustainable way, so that you can plan for change. You want to be able to think about which patterns you should use (and which to ignore for now) to allow for change.

Learning While Doing

Both Lean-Agile and waterfall have a Plan-Do-Review-type cycle. There are two primary differences between them.

A matter of scale. Waterfall iterations are so big that the changes tend to be quite large.
A problem of mapping. Waterfall was created for an engineering project where compliance is very important and where change is quite hard and expensive. Software is a creative process. You discover much by coding things, doing things.
An unnecessary constraint. Software is easy to change. We want to allow change to happen. It is why we call it software.

A podcast series with Scott Bain

In this introduction, we cover:

What are design patterns (and what are they not)
Are design patterns still relevant?
Patterns, TDD, and change
Patterns as part of the language of professional developers

In the future, I will try to get Scott back to work through an example.

Recommendations - Training by Net Objectives

Recommendations - Reading

Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Estimating in Lean-Agile (and a mea culpa)

jim.trott@netobjectives.com (Jim Trott) — Wed, 18 Oct 2006 06:00:00 +0000

Note: I am re-publishing this entry because a few weeks ago, I messed up and had the wrong link to the podcast. It directed you to a conversation about domain analysis rather than estimating. Several alert listeners have pointed this out, and I appreciate it. My apologies! And don't hesitate to keep me honest: jim.trott@netobjectives.com The correct link is below:

Estimating in Lean-Agile

Stories should be between a half day and 2 days. If we cannot get it down to a couple of days, then we don’t really understand the problem yet. This is especially true for new code and new features. Of course, there are code bases that require more than a couple of days, but these tend to be code bases that already have code quality issues.

The big benefits of having stories that about 2 days in length are:

Developers understand what to do before they start working on the code
Management can understand the progress that is being made, by tracking the velocity of story burndown.
You avoid thrashing and being overwhelmed by having too many small tasks, having to go back to the well to try to figure out what is next.

Sometimes, teams are reluctant to give estimates, especially when they have been motivated by fear and they have been whacked when they give bad estimates. Metrics can be used as a weapon. And that is too bad, because in new environments and with waterfall methods, it can be really hard to make good estimates. That’s when we resort to rules like “double it and add 10%”.

This can arise when management requires a certain fixed number of features be released according to a fixed release schedule, without knowing if that is reasonable. In such situations, the only variable is code quality: you get features that are released, but with bugs that then have to be fixed in future cycles (but that is in the maintenance budget, so doesn’t count against you.)

Helping teams build better estimates

Very frequently, the people who are tasked with estimating projects ask the Lean-Agile coach for help in developing better approaches for estimating. They know that this is a big problem. They want to do better, both to build their own credibility and to give management the ability to prioritize better.

To help them, Rod Claar does what most Lean-Agile coaches usually do: ask questions that help them think (rather than simply giving answers).

What have you done and how has that worked for you?
Did you work hard? Could you have worked harder?
How do you know it has not worked?
Did you learn a lot? In what specific ways did you refine your process based on what you learned?

If it is possible to jettison the heavy up-front analysis in favor of Agile analysis, that is best. If the business requires that up-front analysis, then perhaps the coach can help management take a middle path: do everything that they would normally do in an upfront analysis effort, but time box it and put iterations around it. Thus, do a Planning Game for a week, then do development for a month, and then look at what was learned and plan again. This gives the benefit of the iterative approach while not really costing the business any more – they still get a good reasoned set of requirements at the end of a month. And you can still give them a 6-9 month plan, but it is updated after every (30-day) iteration.

To effect this sort of change in estimation, the coach has to have the conversation both upstream, with management, and downstream, with developers and available customers. And the conversation must take place fairly early, say in the Define stage – especially if the decision to go Agile is coming from the top.

And, increasingly, we are seeing the need to go Agile coming from the top of the IT organization.

Recommendations - Training by Net Objectives

Recommendations - Reading

Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

(Design) Patterns and Lean-Agile

jim.trott@netobjectives.com (Jim Trott) — Wed, 18 Oct 2006 06:00:00 +0000

Patterns and Lean-Agile

In other podcasts, we have talked about the “Three Legs of Software Development”: management processes, developer processes, and technical skills. “Technical skills” involves both Design Patterns and Test-Driven Development.

But are design patterns still relevant? Or is that so 1990’s?

The answer is “Patterns are more relevant now than they ever have been… and especially for Lean-Agile software development." Why?

To answer this question, I am turning to Scott Bain, a senior consultant and one of the premier experts in patterns and test-driven development. He teaches and coaches three Net Objectives courses: Design Patterns Explained, Advanced Software Design and Test-Driven Development. He has thought deeply about patterns and Lean-Agile.

A Podcast Series with Scott Bain

This begins a series of podcasts with Scott, where you will start to get a sense for what he is thinking . You will also get a great idea of who Scott is – and if you ever get the chance to take a course from him, it is worthwhile!

In this series, we will cover:

What are design patterns (and what are they not)
Are design patterns still relevant?
Patterns and change
Patterns as part of the language of professional developers

Obviously, we can’t go too deeply into patterns in 15 these introductory podcasts. But I want you to have some ideas for what patterns are and why they are important to the Lean-Agile software developer.

Below are some of what Scott covers.

What are design patterns?

Scott prefers to think of “patterns”, not “design patterns”. In the pre-Agile, waterfall-methodology days, we thought of design as a discrete step you did before creating code. That approach never worked very well – change always overwhelmed the system.

Thinking about patterns – rather than “design” patterns – allows you to think about your work and the things you do again and again that create value. A pattern is like a “bag” of compiled, collected wisdom that discusses things we do repeatedly to solve a particular kind of problem. We give them labels so that we can remember them and access them more readily.

So, there are patterns in analysis, in design, in re-factoring, in testing, in deployment, in implementation.

Are patterns still relevant in the Lean-Agile world?

Yes! They are even MORE relevant

The reason is that in the old days, our biggest expense, our biggest constraint, was the machines and the software. Programmer time was cheap in comparison, so we didn’t mind making people do more if it resulted in more machine efficiency.

Today – and the Lean-Agile world recognizes this – it is the reverse. Computers are relatively inexpensive. Software is ubiquitous. And programmers are relatively expensive. Doing what we can to make people more efficient is crucial. And that includes increasing the communication of wisdom from person to person. (You could think of this as part of what I call Knowledge Management)

One way to think about this is that, in the 90’s, we did what we could to make things easier for the computer, and if that caused programmers problems, well, that’s OK. Today, that is not OK. That is “waste”.

Patterns help us create software that is more maintainable and more robust, at the expense of making the computer do a bit more… and that is great! And this is very consistent with Lean-Agile: eliminating waste, favoring process improvement, valuing local knowledge, and creating robust systems.

If at all possible, I’d recommend taking our TDD and our Design Patterns courses, which has helped hundreds of developers gain the understanding they need to work with patterns and how to access the language of professional developers worldwide. The book, Design Patterns Explained, is also a great place to start.

Recommendations - Training by Net Objectives

Recommendations - Reading

Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Lean-Agile, the Senior Developer, and Progressing toward Maturity

jim.trott@netobjectives.com (Jim Trott) — Sat, 23 Sep 2006 06:00:00 +0000

Lean-Agile, the Senior Developer, and Progressing toward Maturity

Sometimes, as a coach, you encounter a team who knows their domain really well. They have been developing applications in this space for a long time. They may not see the need to change to a new method, when the usual approach has worked just fine, thank you.

Agile just seems foreign to senior developers who know their domain really well. They may resist. They probably do not understand why they need to change and have little incentive to do so. They have to climb a fairly steep learning curve to get out of their old habits.

It takes a while for teams to become efficient in Agile. Our experience shows that the first few iterations may actually be less efficient than using the more traditional approaches, until the team’s mindset starts to change. Rod Claar's rule of thumb is

For a team to get truly proficient in agile, it will often take the same number of iterations as the number of stable members on the team.

Thus, if you have 8 members on your team and you are doing 4 week iterations, you can expect the team to be truly proficient in about 8 months. They will certainly start making progress sooner, but won’t be rock-and-rolling until later.

As a coach or a ScrumMaster, part of your job is to set expectations. It is crucial that you caution the team and the management about how long it will take them to get efficient, so that they do not lose heart. This is especially important if they have been exposed to some of the hype that can surround Agile.

There are several reasons for this.

Lean-Agile is all about continuous process improvement. You will be making changes and tweaks to your processes all the time; you can expect major tweaks as you start out and are still learning.
Lean-Agile is about adapting to a context. What works in one team and one context will not translate exactly to another team and another context. That is why we teach principles and give descriptions of practices in other places and then coach teams in how to work it out for themselves.
Adults take time to unlearn approaches before they can learn new approaches. Transition is hard. The more they understand the motivations to change, the easier it will be for them.

Senior developers often see problems sooner

This is both good and bad.

Based on their experience, they can identify problems that they know will come up and can move to solve them more quickly.
But they might try to build solutions that anticipate problems that might arise in the future. The problem here is that those problems may never come up and you end up with applications that are more complex than is required.

One common example is building general frameworks. How many times have you seen developers build elegant frameworks that allow subtle and varied ways to interact with an application? They can be nightmares to maintain. And yet the developers become enamored of their solution and end up spending lots of time and building in lots of features that are rarely, if ever, used. In Lean-Agile, this is called “Waste”.

The overuse of design patterns is another good example of this.

Now, frameworks are good and design patterns are good, but we prefer to see them built and used based on an evolving understanding of the environment. The requirements should give you the hints about what is needed next. You want the requirements to “pull” the framework, rather than pushing a framework on a system.

Scott Bain discusses this in his new book on Emergent Design. Rod thinks the same could be done for Emergent Database Design: the interface between systems needs to emerge over time.

A series of conversations with Rod Claar

This show begins a series of conversations with Rod Claar, a Senior Consultant with Net Objectives. Rod is a Lean-Agile coach and a trainer in design patterns and test-driven design. He has worked with many clients as they begin their journey into Lean-Agile approaches. In this podcast, we will cover:

Lean-Agile Meets the Enterprise Data Group
Lean-Agile, the Senior Developer, and Progressing toward Maturity
Estimating through Stories

(Do those sound like the titles to a cheesy sitcom from the 60’s? Oh well…)

Recommendations - Training by Net Objectives

Recommendations - Reading

Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott
Reading recommendations which include testing and validation
Creating a Lean Culture: Tools to Sustain Lean Conversions, by David Mann
Managing Transitions: Making the Most of Change, by William Bridges (maybe the best book on Transition Management I have read)

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Author:

Jim Trott

Blog Type:

Podcast

Lean-Agile Meets the Enterprise Data Group

jim.trott@netobjectives.com (Jim Trott) — Wed, 20 Sep 2006 06:00:00 +0000

Lean-Agile Meets the Enterprise Data Group

Enterprise data is an extremely valuable asset that must be protected. Data stewards work very hard to avoid damaging the data and writing high performance code that won’t bog down the data systems or the code that is accessing it.

“To protect and to serve” would be the motto of the data steward, and that is sometimes a hard balance to achieve. Especially when it comes to Agile projects whose designs tend to emerge over time.

When it comes to working well with enterprise data, what kinds of things should the Lean-Agile coach think about?

Acknowledge that data stewards have legitimate concerns
Break down the barriers between data stewards and developers
Allow the data stewards to follow their own processes
At the same time, management must encourage data stewards to see themselves as part of the team, with a duty to support the development project

Decoupling application development from the data system

One of the issues that comes up in larger organizations is that they try to isolate the database team from every application development team. Then, they end up with dozens of database access routines, each one doing the same job. They end up with lots of redundancy, which exposes them to the likelihood of errors. This is a problem of code quality.

This is something that the technical owner, with a lean perspective, should look out for. Perhaps think of it as a decoupling of development teams or processes into work cells.

The database team then is responsible for ensuring code quality for routines accessing the database.

Decoupling allows both teams can work independently. So that the database team can do whatever they need to – normalize, stored procedures, etc. – they can. You want to avoid redundant accesses to the database. This requires design patterns and a relentless focus on code quality across all of your processes

A “Work Cell Approach” to Involving Specialty Areas on Agile Projects

Ideally, the data steward is part of the Agile development team. This ensures the highest bandwidth communication between developers and DBA. However, data stewards are usually in short supply. Organizations cannot staff every project with its own DBA.

One approach from Lean is to make a senior developer the “Agile DBA” for the team, someone whose job it is to look out for the interests of the data, doing simple things, and serving as the liaison with the data steward team. The Agile team treats the data steward team as a separate “work cell”. They flow requirements to the data steward work cell queue, which then pulls the work from the queue in the normal, lean way. Within the data steward work cell, they use whatever methods and techniques make sense for them, interacting with the Agile team’s liaison as needed. This approach recognizes that they have special work requirements, longer lead times, performance issues, etc. and allows them to enough autonomy.

This work cell approach works well for many situations in which highly specialized work is required, such as user interface or data security.

This approach requires discipline and lean thinking and must be accounted for in work iteration planning, so that the components are pulled in at the right time. The Technical Owner and ScrumMaster will want to be in regular communication with their counterparts in the work cell.

To increase communication with the work cell, invite a representative of the work cell to the initial Define activity so that they can give their input. And then, invite them to the Planning Games for each iteration that will involve them.

These work cells should be explicit parts of your Value Stream Mapping effort.

You can even do DBA in an Agile way…

The reason we use an agile process is that we do not understand the domain and the world changes. Agile processes allow more points of change in a very disciplined way. DBAs face this same challenge of change. It is reasonable to think you could even run a database group in an Agile way, though most groups would have a hard time with that.

For the time being, it may be best just to treat them as a separate work cell with their own approach and let them watch the Agile teams, until they are ready to try it on their own – perhaps in a small way.

A series of conversations with Rod Claar

Lean-Agile Meets the Enterprise Data Group
Lean-Agile, the Senior Developer, and Progressing toward Maturity
Estimating through Stories

(Do those sound like the titles to a cheesy sitcom from the 60’s? Oh well…)

Recommendations - Training by Net Objectives

Recommendations - Reading

Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott
Reading recommendations including testing and validation
Creating a Lean Culture: Tools to Sustain Lean Conversions, by David Mann

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Does writing tests up front really take longer?

jim.trott@netobjectives.com (Jim Trott) — Wed, 06 Sep 2006 06:00:00 +0000

Does testing make your OO project take longer?

"Writing tests up-front sounds good in theory, but in practice, doesn't testing like this really take longer in an object-oriented way? Don't design patterns make it harder to write tests?" That was a question I received recently. The answer is no, but not why you might think.

One of Alan Shalloway's favorite sayings is "Fixing bugs does not take very much time... finding bugs - that's what takes time. Once I know where the bug is, it is usually easy to fix." And this only gets worse as your system grows more complex or goes through more releases / revisions.

Lean teaches us to focus on the entire value stream, to aim for perfection, to optimize the whole. One way to do this is to capture mistakes early and never to let mistakes repeat themselves. That is why we advocate writing tests early, testing automatically, and keeping your test suite up to date.

Using your time to write tests that help you find bugs is ultimately more efficient and speedier than spending lots of time debugging code. Particularly if you are writing code that is meant to endure and grow. You might say,

"Debugging is for a moment; tests are forever."

Alan shares how he learned this the hard way - that writing more tests means writing fewer traces. And how writing object-oriented code actually requires upfront testing... Think "trust, but verify" - you want to know that you can trust an object.

Recommendations - Training by Net Objectives

Recommendations - Reading

Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott
Reading recommendations including testing and validation
Creating a Lean Culture: Tools to Sustain Lean Conversions, by David Mann

Recommendations - Tools

VersionOne, for Agile Life-cycle Project Management

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Seeing QA's as allies - The Lean-Agile Way

jim.trott@netobjectives.com (Jim Trott) — Wed, 30 Aug 2006 06:00:00 +0000

Seeing QA's as allies

Good QA people are very valuable. Whether they are working in traditional or agile environments, they bring to bear many of the same tools and skills. So, what is special about working on a Lean-Agile team? How should QA's see themselves as part of the team? And how should management see QA?

My neighbor told me a story of two QA guys who worked at his software company. They had received great performance reviews for creating a good testing culture and a great process. Then, they were transferred to another department where testing was informal and developers were managed more by fear. These QA's continued to do their job, testing, capturing bugs, offering suggestions, looking for ways to partner. But after their first year, they were trashed in their performance review and threatened with dismissal for poor team spirit! What made the difference? Neither group was particularly agile. But management in the first group saw QA as an ally while in the second group, they saw QA as a threat.

Lean-Agile software development emphasizes the spirit of the first group: testing is an ally.

In the last podcast, Alan Shalloway talked about testing within Lean-Agile. Now, we are going to dive a little deeper.

How does lean and agile inform the QA practice?
What are some of the skills you should know?
Why do we emphasize so strongly the importance of writing acceptance tests up front before any code is created?

Lean sets a larger context for QA. Lean says that everyone has two responsibilities:

Run the business
Improve the business

Thus, lean teaches that you always want to pay attention to process. Follow the process. When something breaks, find root cause, improve the process, and then go. It requires discipline to want to improve. That is how you improve the process.

In Lean-Agile Software Development, this is done by a relentless commitment to testing. Always write tests before you write code. This is part of the discipline and the skill that is required to be successful in Lean-Agile. Lean gives everyone - including management - a framework for understand testing's role and actively encouraging it and creating compensation systems that help it. Lean encourages and indeed requires the teaming of developers and testers to work together to deliver quality and value to customers.

By the way, those two testers? My neighbor, their former manager, intervened for them all the way up to the division Vice-President. Their reviews - and compensation - were adjusted. One stayed with the company. The other left. There is a great demand for good testers.

Recommendations - Training by Net Objectives

Recommendations - Reading

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

QA is fundamental to process improvement in Lean-Agile

jim.trott@netobjectives.com (Jim Trott) — Wed, 23 Aug 2006 06:00:00 +0000

QA and testing

Do you use Quality Assurance in your coding practice? How do you use it? And when? And why? What drives you to do testing when you do it?

We claim that QA is one of the most important facets of Lean-Agile software development. More than simply catching bugs or verifying user requirements, they are also partners in helping you improve your entire process. And yet, it is generally misunderstood and under-appreciated.

In the last podcast, Rob Myers told a story about how testing can be misunderstood. This prompted me to want to explore in more depth testing and QA within the Lean-Agile Software Development framework. This podcast is part 1 of an interview with Alan Shalloway, who shares his perspective of QA in its role in overall process improvement in Lean-Agile.

Fundamentally, the goal is to change our perspective from "I am producing a product" to "I am always trying to add value to the customer" (in line with business goals). What we are after is:

Changing the dynamic of the conversation between the developer, customer, and tester
Creating a positive, knowledge-generating environment in which process improvement happens naturally and quickly
Automating this so that it becomes part of the standard work of the team
Augmenting the nature of documentation to include executable specifications that are always current

Recommendations - Training by Net Objectives

Test-Driven Development

Recommendations - Reading

Reading recommendations including testing and validation

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Notes from Agile 2006 and Comments on Testing

jim.trott@netobjectives.com (Jim Trott) — Tue, 15 Aug 2006 06:00:00 +0000

Notes from Agile 2006 and Comments on Testing

The Agile 2006 conference has come and gone. It was a good and eye-opening experience for me. I had lots of great conversations in the Net Objectives booth and over coffee. I got to help lead a session or two. And I had fun with customers and colleagues. All for something I really believe in, this connection between lean product development, agile software development, and technical skills, supported by lean management systems and tools.

In this podcast, I thought I’d share two or three observations of my own observations from the show and then ask Rob Myers to talk about a conversation he had in our booth with a skeptic. We are going to be turning to issues around testing and QA and this makes a good start.

I used this graphic to describe what we mean. I got to calling this the “three legs of the stool” for effective software development

VersionOne is cool

VersionOne gave away the coolest stuff: mini-rugby balls and rugby shirts (for Scrum). And their large screen TV had the "sizzle" factor, showing off the VersionOne tool quite well. And their tool is very nice. I am using it now and find that it works like I would expect and does not get in the way. Just what you’d hope for in an agile project support tool.

We partnered with VersionOne to offer a cruise as an expression of thanks to our customers and associates. And to give them and us a chance to talk and connect. It was a lot of fun, a great way to unwind at the conference. Both of us hope to make this an annual event at the Agile conferences.

Here’s a picture of the sternwheeler we went on. With thunderclouds in the distance, it was a gorgeous evening.

Mature Questions

The next thing I’d note is that people are serious about this stuff. There are people looking for what to do and many looking for what to do next, now that they have been using Agile for a while. There were a lot of great, insightful questions. Lots of good, practical insights being shared, together with some academic lessons.

It is clear the field is still growing. There seemed to be a good balance in topics, covering the “iron triangle” of people, process, and technology. When people issues are being talked about at a software conference, that is a good sign.

Hybrid Methods

It also seemed to me that almost no one is using a “pure” methodology, as defined in a book. Most companies I talked to are using a hybrid solution, choosing from among several approaches and adapting them to fit their own context.

And that is as it should be, in my opinion. Just because someone made something work in one context in one company doesn’t mean I should be able to bring those same practices and techniques over to my context and my company and expect them to work as is! I’ve had too many vendors come talk to me with their packaged methodology and, by the way, a tool ($$$) to support it. They are just trying to sell something and it has never worked out for me.

What works better is to understand the principles and strategies underlying a methodology. Then read about how the methodology is practiced at other companies to give me guidance and ideas about how I might use it at my own company.

That takes some thoughtful work. A friend of mine last night said, “but Jim, a lot of people simply want to be led, to be told what to do.” And that is where I would say, OK, there are lots of people who will take your money and tell you what to do, but it won’t be effective for you. This is knowledge work and learning and feedback and evolution are where it is at. So, it is better to have an experienced coach who can come alongside you and help you think about what will work for your situation and how to evolve an approach that fits your needs, that you can own.

Anyway, that is what I believe. And it seems that that is what many people are looking for. And it is the approach that people who are successful are using.

I want to use tools that fit me, not the other way around

Along that line, I also heard people say that tools were important. They are progressing beyond simply using stickies on a wall. They want to give visibility to governance structures about what is going on and to help them assess progress across the development and maintenance efforts. So that work can be prioritized and future iterations can get funded. Reporting is important.

But people want tools that can adapt to their hybrid methods, rather than forcing them to adapt to the tool’s methodology. I heard many people say they were resorting to writing their own tools, and that was going OK. Vendor tools that were interesting had to be flexible and light weight enough to adapt.

It is a balancing act. Whatever tool set you use, you want it to report enough and report accurately and yet you don’t want to impede the development team. It seems that is often yet another thing that falls on the ScrumMaster. And it is important.

Working a Booth is Fun and Work

One of the great things about working a booth at a show. Of course, there is a lot of mechanics to the booth itself – we tried to make ours a comfortable place for conversation (as much as a booth can be). I suppose as a training and coaching company, that is only appropriate. What we offer is who we are and the principles and practices we teach, and that usually involves talking… and trainers are always up for talking! Beyond the mechanics, you learn so much about how to communicate your message in a short time and get to listen to many reactions to that message. And you get to see what other vendors are up to and their approaches. It is an intense and educational experience. If you ever get a chance to work a booth for something you really believe in, take it. You will learn so much!

Conversations with a Testing Skeptic

The podcast contains a brief, 6 minute conversation with Rob Myers, a Net Objectives expert in XP and Testing. He had a conversation with a skeptic about testing. She had seen too many times where testing did not work – the code passed the test but the code was still wrong. Rob discussed the difference between UAT and Unit Testing. They require different strategies and timings and rationale in an agile context.

Testing should support your work on future releases. And it should help you know that your code is “Four Done”

Done: The system runs on the developer’s computer as expected.
Done: The system is verified by running unit tests, code review, etc
Done: The system is validated as being of deliverable quality with functional tests.
Done: The system is ready for production.

I want to spend several shows on this important area in the near future.

Recommendations - Training by Net Objectives

Test Driven Development

Recommendations - Reading

Reading recommendations for testing and validation, including FIT

Recommendations - Tools

VersionOne, for Agile Life-cycle Project Management

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

An Interview with Ken Pugh - Seen at Agile 2006, People Issue are Quite Common

jim.trott@netobjectives.com (Jim Trott) — Wed, 09 Aug 2006 06:00:00 +0000

Interview with Ken Pugh

Ken Pugh is an expert consultant with a ready smile, great instincts, and, like so many of the experts and trainers I have had the pleasure to work with, he takes particular joy in watching the light bulbs turn on as he works with students. At Agile 2006, Ken talked with me about one of his key observations: most agile teams have challenges with people, yet most of the training developers receive still focuses on technical skills. In some sense, that can set them up for failure.

People issues show up in several forms:

A person who does not want to collaborate or cannot collaborate
Time problems (too many meetings, etc)
A developer who simply plows ahead for rear of asking questions and looking incompetent
Conflict resolution
Difficulties in communication

This is perhaps especially a challenge in individualistic, highly competitive, or isolated environments. So, what do you do? Do you exclude people who cannot fit in? Or do you work with them to help them transition or to find alternatives?

The key is not to force the solution on the individual, not to impose a fix. Instead, you have to work with the individual to help them discover the solution. This is sensitive and tough work. In Scrum, this would be a primary responsibility for the ScrumMaster (who is responsible for focusing on the health of the team).

In Scrum, it means that ScrumMasters must learn "soft skills", how to work with people discover their own solutions. There is no way around this. To help with this, Ken recommends books by Jerry Weinberg.

This relates quite well to last week’s podcast on interviewing techniques for staffing agile teams, above.

Ken has been in business since 1982, offering OO, Java, C++, C, customer programming, design, process issues, and expert testimony, with its headquarters in Durham NC. If you get a chance to hear Ken speak, I highly recommend it. His speaking schedule is on the Pugh-Killeen Associates website.

Recommendations - Reading

By Jerry Weinberg

Recommendations - Online

Weinberg's Blog, Secrets of Consulting: http://www.geraldmweinberg.com/
Ken Pugh's website: http://www.pughkilleen.com/

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

ScrumMaster Overview – Part 2

jim.trott@netobjectives.com (Jim Trott) — Mon, 17 Jul 2006 06:00:00 +0000

An Overview of ScrumMaster - Part 2

The Agile method called Scrum empowers the “Team” (the group of developers and the business working together to produce product) to decide together how to do their work without lots of external influence. People who are used to working in a hierarchical, specification and deliverable-oriented environment may have a lot of trouble at first with this combination of freedom and responsibility. It can feel very disorienting.

So, within Scrum, there is a role called the “ScrumMaster” whose job it is to help the team with this transition, to stay healthy, and to stay focused on producing product (that's the "hand" in the diagram on the right).

It is a hard job!

I am running a little Scrum project for a relief and development organization I support. The team is composed of college interns editing and producing video training. They are quite uncomfortable with the freedom I am giving them, and appreciate why I am doing it. It has made for some involved conversations to help them see what they are supposed to do, how I am there to help but not to do and not to dictate. So, I really appreciate the difficulty that ScrumMasters face.

This podcast is Part 2 of a "ScrumMaster Overview" conversation I had with Doug Shimp, a Certified ScrumMaster Trainer and former senior consultant with Net Objectives. so if you haven’t listened to Part 1 yet, I’d encourage you to take a listen.

In Part 1, Doug covered these issues around being a ScrumMaster:

Where did the term “ScrumMaster” com from?
The qualifications and personality types and organizational origins of good ScrumMasters
How many teams one ScrumMaster can serve
Impediment removal

In Part 2, I continue my conversation with Doug, covering these issues:

Examples Doug has seen of both good ScrumMasters and those that have challenges
The partnership between the ScrumMaster and the Product Owner.
How to become a ScrumMaster. (which is quite similar to the process for becoming a Lean-Six Sigma Greenbelt)
Why every team member needs to take the CSM training.

Why is it so hard to find good ScrumMasters? Consider these characteristics that a ScrumMaster must have:

Humble enough to serve the team
Strong character and confident enough to stay in the background, promoting the team.
High integrity and high trust relationship with all the team.
Politically savvy with a strong relationship with product owner
Able to understand both business and technical people

Note: This podcast jumps right in to the phone conversation I was having with Doug, so it might seem to start a little abruptly.

Recommendations - Training by Net Objectives

Scrum

Recommendations - Reading

Reading recommendations for Agile Practices
Agile Software Development with Scrum by Schwaber and Beedle

Recommendations - Tools

VersionOne, for Agile Life-cycle Project Management
Wikis and Spreadsheets (no particular recommendation here)

Recommendations - Online

Concango's Scrum FAQ Podcast Transcripts

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

ScrumMaster Overview - Part 1

jim.trott@netobjectives.com (Jim Trott) — Fri, 14 Jul 2006 06:00:00 +0000

An Overview of ScrumMaster - Part 1

I was in a meeting last week with a number of Chief Information Officers. One of the speakers, talking about Agile and Scrum, used the term “Scrum Master” and got a lot of blank stares. They had no idea what she was talking about.

This is a fundamental role in Scrum, one of the better approaches for Agile software development. There have been some good articles and books written about ScrumMasters and there is formal Scrum Master Certification by Net Objectives course available. Yet, the term seems to get in the way of understanding the role.
Note: Net Objectives is not affiliated with the Scrum Alliance.

This is because the terms “Scrum” and “ScrumMaster” were chosen because they were essentially value-free. Thus, the developers of Scrum were free to “pour” their own meanings into the terms. This has proved to be both a blessing and a curse.

"ScrumMaster" is probably a good term, within the context of Scrum. In particular, "ScrumMaster" is not a “Project Manager”, which is loaded with so many concepts as not to be useful and yet seems a bit stronger and more connected than a “Facilitator.” To me, it seems more equivalent to a Green Belt in the Six Sigma sense.

The ScrumMaster role is fairly unique. It is a servant role – someone whose focus is the health of the team on their ability to produce product as quickly as possible. Usually, this means they must sacrifice their own desire to create code so that others can do so. They must be trusted and trustworthy, able to listen, and tenacious in representing the team to the outside.

Where do ScrumMasters come from? They can come from anywhere in the organization. We have seen a lot of good ScrumMasters come from the QA department – they seem to have the right mindset. Project managers can be good ones, but it often requires them to readjust their thinking.

To get a handle on this, I had a conversation with Doug Shimp, a former senior consultant and Certified ScrumMaster Trainer with Net Objectives.

I decided to break my conversation with Doug into two parts to make it easier to listen to.

In Part 1, Doug covers these issues around being a ScrumMaster:

Where did the term “ScrumMaster” com from?
The qualifications and personality types and organizational origins of good ScrumMasters (approachable, people-oriented, detail-oriented, politically-savvy. They have to have the right mindset.)
How many teams one ScrumMaster can serve
Impediment removal. One of the main jobs of the ScrumMaster is to help remove impediments to progress but it is not (always or even often) her job to remove them. She must help prioritize the effort to remove them, track progress, and help the team decide when to fight and when to work around it.

In Part 2, I continue my conversation with Doug, covering these issues:

Examples Doug has seen of both good ScrumMasters and those that have challenges
The partnership between the ScrumMaster and the Product Owner. He is a partner with the entire team, both developers and the Business. The ScrumMaster has to help the Business think about the product and the problem they are trying to solve, and the questions they should be asking.
How to become a ScrumMaster. This involves a learn-by-doing approach very similar to the Six Sigma Green Belt process, involving training, experience in running a project under a coach, and coaching a project, making a report out.
Why every team member needs to take the ScrumMaster Certification training. Helps the team understand what scrum expects of them and what they can do to help the ScrumMaster help them do their work
Budgeting and project management and the ScrumMaster
Tools and infrastructure you need to know

EDITOR'S NOTE
Doug lives in the midwest and I am in Seattle. So, I did this interview on the telephone (I got his permission first!). But what do you think? Does this sound OK to you? Is it irritating? Drop me a note and let me know what you think.

Recommendations - Training by Net Objectives

Recommendations - Reading

The Scrum FAQ Podcast Transcripts at blogs.conchango.com
The Net Objectives bibliography for Agile Practices
Agile Software Development with Scrum by Schwaber and Beedle

Recommendations - Tools

VersionOne, for Agile Life-cycle Project Management

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

The Technical Aspects of Lean-Agile

jim.trott@netobjectives.com (Jim Trott) — Wed, 05 Jul 2006 06:00:00 +0000

The Technical Aspects of Lean-Agile

A lot of our podcasts have been focused on process and on roles – especially the product owner role. And indeed that seems to be what much of the Agile community seems to focus on. Because together, they help us make a lot of progress quickly. But they are not enough. In the corporate world, we always talked about paying attention to the “Iron Triangle” – People, Process, and Technology. All three are important. If you don’t have a balanced emphasis, the “machinery” of your development process will soon grind to a halt.

In this podcast, Alan Shalloway starts bringing a focus on that third side of the triangle: the technical aspects.

Now, maybe this reflects Alan’s bias as an educator, because by “technical”, he is primarily focusing on the technical skills of the development team rather than on specific tools. Developers have to have the mindset and the skills to use their tools in a Lean-Agile way. That said, there are tools and infrastructure aspects to consider.

Technical skills for developers include the following:

Requirements analysis.
Building minimally functional systems.
QA and Acceptance Testing, especially using Fit – Framework for Integrated Test – and FitNesse. This is because it is very important to move QA to the beginning of development.
Lean-Agile Architectures through Design Patterns. Software architectures define relationships within which software components fit. Creating architectures that allow your system to change, to encapsulate variation. This directly supports a key lean principle: Defer commitment.
Test-driven development. Creating your tests up front so that you can design to interfaces and your product is always perfect. How to refactor, how to test.
Extracting stories from use cases. Especially if you work in environments that is used to creating heavy use cases.
Object-orientation. Nothing helps you understand how to create code that can be modified with minimal impact better than a good grasp of object-orientation.

Infrastructure requirements include the following:

Source code control
Automatic builds
Project management (such as VersionOne)
Coding standards. The team has to figure out their coding standards, but using the same tool really helps.

Recommendations - Training by Net Objectives

Recommendations - Reading

Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott
Reading recommendations including testing and validation

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

alshall

Blog Type:

Podcast

Agile Needs a Product Owner

jim.trott@netobjectives.com (Jim Trott) — Wed, 21 Jun 2006 06:00:00 +0000

Why you need a product owner for Agile

The Voice of the Customer should set the priorities and vision for the product you seek to deliver. But getting a handle on that Voice can be really hard. Customers can be hard to pin down. They may feel like they are too busy to talk to you or too far away to engage with them successfully. Often, there is more than one customer with a variety of demands – even conflicting demands. And then how do you decide who to listen to?

Have you ever found yourself in that situation? Have you found yourself having to guess what customers want? Or, even worse, having to rely on the Marketing department to guess for you? Has that worked well for you?

Guessing never works well for me. And it violates one of my fundamental rules for project management: Assume Nothing. Never assume you know what the customer is wanting. Never assume an impediment is too hard to overcome. Never assume a requirement is written in stone. Assume Nothing. Ask someone who knows.

The Lean-Agile solution to this challenge is the “Product Owner” role. We discussed this in the Product Owner as part of the Product Development Team podcast. But because the Product Owner is so central to Lean-Agile approaches, it seemed good to get an additional perspective. So, I am turning to Alan Shalloway to get his take.

Recommendations - Training by Net Objectives

Design Patterns

Recommendations - Reading

Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Lean Product Development is the Right Approach for Software Development

jim.trott@netobjectives.com (Jim Trott) — Tue, 06 Jun 2006 06:00:00 +0000

Lean Product Development is the right approach for software development

Toyota can bring new products from initial concept to the production floor in 18 months while other manufactures may take twice as long. Some software companies seem to have a knack for understanding what customers really want while others go through many versions to get something that merely works.

What is the difference? Their approach to new product development.

Toyota discovered that applying lean principles to the development and design of their products is somewhat different from lean applied to production and manufacturing. The goals are different and so the application of the tools is different, too.

Michael Kennedy describes product development as “the collective activity or system that a company uses to convert its technology and ideas into a stream of products that meet the needs of customers and the strategic goals of the company.” Product development is process of discovery. Discovering what customers desire and need and then designing product that will meet that. Indeed, perhaps 70% - 80% of a product’s cost lies in this discovery process; the production is relatively straightforward.

In this show, Alan Shalloway argues that this is also true for software development. The process of discovery of what customers desire and need is by far the largest contributor to the cost of the software product. Therefore, learning how to apply the principles of lean product development to software development is essential to an effective software development process.

Elements of Lean Product Development include:

A relentless focus on what the customer desires, wants, or needs
Driving out waste – the things we do that do not help us understand what the customer wants or that get in the way of creating product that satisfies those needs.
How to manage intellectual work

Software lives in the larger context of the business. Lean helps set the context in which software fits in the business.

Before the how, we have to understand the why.

Recommendations - Training by Net Objectives

Lean Software Development

Recommendations - Reading

Product Development for the Lean Enterprise: Why Toyota’s System Is Four Times More Productive and How You Can Implement It by Michael N. Kennedy
The Machine That Changed the World : The Story of Lean Production by James P. Womack, Daniel T. Jones, and Daniel Roos

Music used on this podcast:

For more informaiton, send us an e-mail at info@netobjectives.com or visit www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast

Lean-Agile Straight Talk: An overview of Lean-Agile Software Development

jim.trott@netobjectives.com (Jim Trott) — Tue, 30 May 2006 06:00:00 +0000

An Overview of Lean - Agile Software Development

Since my days working with manufacturing, I’ve been hearing about Six Sigma and about Lean. There is a lot to these programs. The “elevator speech” says that Six Sigma focuses on reducing variation and Lean focuses on reducing waste.

Last year, I gained my Six Sigma Green Belt certification helping an internal help desk to improve self-service. We used a Lean Six Sigma approach and was a great process, very customer-centric which surprised me. I had thought six sigma was all about statistics. OK, well it had a lot of statistics, which made my little mathematical heart go pitter pat. But there was a lot of human focused work, too. It was fun… and it worked to improve their process.

Great for production work. But does it to software development? It doesn’t seem that six sigma is quite the right set of tools for that.

Alan Shalloway, the CEO of Net Objectives recommended a great book to me: Lean Software Development: An Agile Toolkit for Software Development Managers by Mary and Tom Poppendieck. I loved her book. And the Net Objectives course based on the book was really a lot of fun. It really got me to thinking.

Lean-Agile Straight Talk was born out of a desire to help us and others share our thoughts about this emerging topic with people who really care about being more effective and suffering less to develop software. Without a bunch of hype. So, over this series of podcasts, I hope to explore how this applies to Requirements, product development, testing.

How do you fit it in to an organization that has been used to waterfall processes? Can you do that? How do you help organizations make the transition? What are the human-centered tools that help? What makes for a successful ScrumMaster? And what in the world is a ScumMaster anyway? To start with, it seems like it would be worthwhile to get the 30000 foot view first.

That’s where we will start, with some interviews with Alan Shalloway, CEO of Net Objectives.

Recommendations - Training by Net Objectives

Recommendations - Reading

Lean Software Development: An Agile Toolkit for Software Development Managers by Mary Poppendieck and Tom Poppendieck
Product Development for the Lean Enterprise: Why Toyota's System Is Four Times More Productive and How You Can Implement It by Michael N. Kennedy
Design Patterns Explained : A New Perspective on Object-Oriented Design (2nd Edition) (Software Patterns Series) by Alan Shalloway and James Trott
Agile Project Management with Scrum by Ken Schwaber and Mike Beedle

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Author:

Jim Trott

Blog Type:

Podcast