The 7 Software Development Wastes - Lean Series Part 2 - Overproduction

Introduction

I wish I knew about Lean earlier in my career - I think it could have made the world of difference. Lean offers such practical advice on what to look for in order to make the process better. I think just knowing about these aspects of lean will help you day to day, help you make better decisions, make you a more effective player on a software development team.

Last week I covered the first manufacturing waste In-Process Inventory corresponding to partially done work in software development.

This week I will discuss the 2nd Waste:

Over - Production

Can you rely on Story points

It's always good to know that what you're doing is valid. I found an excellent blog about an experiment that was run by Lance Walton on estimating. He poses the question as to whether or not there is a direct correlation between story points estimated and the sum of task estimate (hrs).

You can read the entire blog here - http://www.stateofflow.com/journal/51/estimation-xperiment

I thought it was a really well written blog and wanted to share it all with you.

What do you folks think?

Jack

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

The 7 Software Development Wastes - Lean Series Part 1 - In-Process Inventory

Introduction

The more I learn about Lean, the more I realize how much we can learn from Lean teachings and how they apply to software development practices. Typically, we go about our day-to-day activities without thinking about the bigger picture. Lean specifically addresses the complete end-to-end process with the view of enhancing cycle time and quality.

Lean

Value stream mapping is one of the key areas for helping us learn where we fail, but in particular, what I'd like to address in the next series of posts are the 7 wastes which Lean identifies and which I believe are worth mentioning. Once you hear about these wastes I believe you will be more sensitive to realizing when you see these manifested in your organization and should therefore help you to enhance the overall productivity of your teams.

Mary and Tom Poppendiek are two of the thought leaders in applying Lean to software development and I would highly recommend that you buy their books or attend their courses. Mary in particular is inspirational and their knowledge in this space is profound.

7 Manufacturing Wastes

The 7 manufacturing wastes identified by Shigeo Shingo (from his studies of the Toyota production system) are listed below:

Switching user stories mid sprint

On the Scrum Development, forum one of the members asked a really valid question. The scenario he presents is as follows:

The Sprint is two days old. The PO comes to the daily standup meeting and advises the team that the one particular story is no longer needed and he wants to switch the user story with one of equal weight. He wants to know what he should do.

My opinion on this is of course - it depends!

1. The team may have already started working on the story. So throwing the no longer needed story out means that the team has lost time already invested. So in this scenario, I would wait till all the other stories are done before considering switching in another story of equal size.

What metrics should you track?

Today on the Agile Project Management forum a question relating to metrics was asked. It was a rather lengthy question, but to paraphrase, he wanted to know what metrics typical organizations use to track projects and should they be tracking metrics such as: Average cycle time committed to UAT (Days), Average cycle time committed to done/Live (Days), Velocity per person etc.

Coping with change on Scrum projects (Part IV)

Having worked in a waterfall environment most of my career, I am all too familiar with the "death march" which inevitably lead to shrinkage in the time left for QA to test the software. Fortunately, for testers as with developers, this story is going to change big time. How so?

#1. You will now be expected to participate right from the beginning of the every sprint. Wow, imagine such a concept. What value can a tester add this early on in a project - I'm being facetious of course. You will be part of the Sprint planning meetings so you'll get to hear right up front what user stories are planned. In fact you will be part of the process of embellishing the user stories themselves. You will for example help to define the user story acceptance test criteria. This significantly helps developers understand what they need to do up front for the tests to pass. And as a result, the quality of the code delivered is dramatically increased as well as the "accuracy" of code i.e. how closely the code matches end user requirements.

Coping with change on Scrum projects (Part III)

Introduction

In the next two posts, I'll take a look at how the lives of QA testers and Developers are expected to change on Agile (scrum) projects. Frankly, I think that for these two disciplines, life gets much better i.e. developers and testers benefit most transitioning to Agile from Waterfall.

Developers

Developers love to do things right. Nine times out of ten, they'll argue against taking short cuts. They hate the fact that they are forced to deploy code that they know deep down is less than stellar. As with anything in life, making the shift to agile swings the pendulum over to the complete opposite side. So for the one out of ten code hackers out there - beware. The biggest change a developer can expect from a shift to agile is that engineering discipline or rigor is set to the max.

So what can you expect?

Coping with change on Scrum projects (part II)

Introduction

Recently, I saw a spate of posts dealing with this very topic - although much more specific. In particular, one of the questions raised was "How does a manager add value on a Scrum team?" This segues nicely into this weeks post in which I intended to cover how the management roles (general managers and project managers) are expected to change in an Agile environment.

General Management

Since Agile teams are supposed to be self managing, where does this leave general management, and what are they supposed to be doing. Hopefully the following will give you some food for thought.

#1. Managers should be there to act as a sounding board for the team, especially if the manager has good experience. This will help the teams avoid the obvious gotchas that many teams especially teams new to Agile make.

Coping with change on Scrum projects (part I)

Introduction

Most folks don't like change. I know I don't. But one things certain, adopting an Agile approach to software development requires much change in an organization. Whether it's corporate culture, roles or process, as an organization switching to Agile you're going to have to learn cope with change. This series deals with how various functions in the Agile organization are expected to change in order that teams new to Agile can learn what to expect and better adapt to this new and invigorating environment. This week covers the changes one can expect for the Customer and Product Management function in the Agile organization.