Lean Software Development Podcasts

This is a great series of podcasts on Lean Software Development. 

Listen to the webinar audio 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 ot 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. 

Full article: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter1 


 Listen to the webinar audio 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: 

  1. 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!
  2. 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.
  3. 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.
  4. 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! 
  5. 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

Full article: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter2-business-case-for-agility

Listen to the webinar audio 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.

Read more: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter3-big-picture

 Listen to the webinar audio 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.

Read more: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter4-lean-portfolio-management 

Listen to the webinar audio 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


Links above are from the Net Objectives website at:  http://www.netobjectives.com/

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s