Who do you charge for the context switch?

Assuming you are billing by the hour… who do you charge for the cost of the context switching between different projects you are working with?

The picture and more information around the topic was found at: http://www.codinghorror.com/blog/archives/000691.html

Comparing Lean and Scrum – What’s the difference?

What’s the main difference between Lean software development and agile methods like Scrum? Until recently, that question has not bothered me at all because I didn’t really care. The principles of Lean software development has helped me to focus on value and waste in software development. Agile values, principles and practices are useful tools when developing software.

But, then it occurred to me that there is really another difference, I’ll try to describe my thought by raising the question to you and your development team: What are you actually selling to your customer, how do you create value?

I’ll give you three alternatives: 1) are you selling a plan, 2) are you selling a team or 3) are you selling a product.

Selling the plan

Selling a plan, to me,  is not agile or lean at all. Let’s say that the customer would like to have some kind of software development, and the intentions, business case etc. are all valid and correct. The customer contacts development company MasterPlan.Net and they will create a plan describing how they are going to create the value needed.

The assumption here is that if we follow the plan, then something valualble will be created. Let’s look at the other part:

Selling a team

When selling a team; the customer can choose to use the team in any way he like, if it is to develop a piece of software, build a house etc. in theory it does not matter.

If the customer has a vision, a product backlog and uses agile methods such as Scrum, then there will most likely come something valuable out from the team every 2-4 weeks.

The cost for producing the software is based on the cost of the team and the number of iterations needed by the team to create a version that meets the need from the customer.

This scenario is much more agile and will respond to change much better than the scenario with the plan. On the other hand, what about…

Selling a product

Let’s assume that there is a software system, and we call it a product. Each feature in the system flows through a value creating process including actions such as development, testing, and deployment.

The challange here, is to transform business needs into business values as efficent as possible. And the development process is a description of the current best way of doing that.

To do this efficiently, a motivated, complete team is created. With the ability to move items through the process. The team uses the concept of Scrum to work in iterations. The team tries to minimize the number of things in process the size of the items in the process so that the speed is maximized.

In the perfect world, features are delivered just-in-time, and development teams pulls work from the input queue. Or even better, it can be seen as a Kanban system… where the order is added last in the process… that’s where the motivations for test-driven development is really clear.

So what’s the point?

Maybe, I’ll really need to describe this in a better way. But for me this states the real difference between Scrum and Lean. Do you see the difference?

Scrum is the framework for helping the team collaborating, to make things flow through the development process.

Lean Software Development, is about creating value, make things flow in the value stream from business need to business value.

It is possible to use waterfall project methods to push things thorugh the value stream, but what you’ll see then is a number of large queues between for example development and test etc. Ie. waste in the lean world… so that is something that we don’t like.

SO, again, what’s the point, Agile methods and Scrum are useful practices to enable Lean Software Developent. For me, that complements the perspective of Lean being a foundation of principles guiding software development.

So, is Lean Software Development applicable when you are developing software in a non-product line environment? Yes, I’ll believe so but more on that in another post. What do you think?

cheers!

Is technical debt waste?

How does technical debt relate to the seven wastes in Lean Software Development?

1. Extra features – I cannot see any direct correlations here
2. Partially done work – If code that is not refactored is not done, then skipping refactoring will be valid here. But I don’t think it is that obvious. Based on that argument, we can actually motivate allmost everyting by this kind of waste
3. Relearning – Does not help me that much here, or?
4. Task switching – Nope
5. Handoffs – Nope
6. Delay – Code that is not refactored will result in delay and will take longer to maintain and make changes to. So, Delay can be an effect, but is not the cause.
7. Defects – Not really, but as with delay, sloppy code will most likely result in more defects or increased cost.

In the book Lean Software Development – From concept to Cash by Tom and Mary Poppendieck, the topic complexity is one of the first topics discussed when waste is discussed. Technical debt will result in increased complexity. Adding complexity into the code is – what I can see – increasing the technical debt.

So, my current standpoint is that putting technical debt into the code base is waste. Removing technical debt is neccessary waste that should not be needed if the sloppy code was not there from the first place.

Then the next question is how we can develop code with minimal technical debt fast enough? Well, write less code, build quality into the software via Test-Driven-Development and constant refactoring might be a good start.

Slack

I’ve just realized the huge impact slack has to development productivity within an organization. I have read the theories, but it is not until I’ve seen it in practice I really get it (or think I get it).

Do you have the guts to create slack to increase productivity?

Go lean !

Is a company wide standard a failure?

Inspired of Mary Poppendiecks post on Lean Software Development

What is true for a company standard? Is it:
1) These standards should be used throughout the whole company
2) We cannot have local customizations of that standard, because then it would not be a company standard
3) If someone finds a better way of working ie. improving the standard, that that change should be communicated throughout the whole company.

If these three statements are true; then I don’t think company standards are something to strive for, for a couple of reasons:

1) It feels like, this standard is the best way to do things, just follow the process and the work will be done..
2) We remove local creativity
3) We as a company get really slow, every improvment turns into a large change in way of working for a lot of people.
4) Instead of enable standards for improvement and efficiency, the standards are things that will prevent people for being productive and creative.

So, how should we think about standards then? I thik the concepts from Lean and Kaizen can guide us here:

Standards are there to describe our current best way of doing things. The teams can choose to follow the standards. The team is accountable and responsible for achieving the result of thier work, if they decide to not follow our current best way of doing things, it is their call.

Let’s assume that it is not the culture of the company to delegate responsibility to the teams. Then the people deciding what the team should do must have a tool to commuicate the directions for the team. Let us also assume that these directions are called company standards. Because these standards describe how we are doing things in this company…

If the team is not responsible for what they are doing, where is the motivation for improvements? I think respect for people and delegating responsibility as close to the work as possible is the key to continous improvements.

So, is a company wide standard a failure? Well, it depends on how the company thinks about the people in the enterprise.

How do you create value in your enterprise?

One traditional way of looking at Software Development is that the development organisation delivers software within a development project. The solution is then maintained and operated in some way during its life cycle. Withe one or more larger change projects happening during the life-cycle.

Looking at the value stream and the principles of lean, the lean organization aims at reducing the cycle time from the need/request of feature until it is in production. Moving focus to features (and we only do the features that provide the highest value right?) we reduces a lot of waste partially done work, extra features etc etc.

In a larger enterprise, with many different processes and also many different sysetms, the need comes from the business in the process improvements rather than in syftem improvements. Well this is just plain old SOA, or?

Looking at SCRUM; you have the product owner and the product backlog. Where the product backlog is an prioritized list of the most valuable featuresets for that solution.

From a business perspective, moving from a system backlog to a process backlog, and the development company/partner/department/team is responsible for eliminating backlog items as effectively as possible. Software development can be a more natural part in business improvements instead of just delivering software.

For me, this aligns very well with what I consder to be Lean.

So my question are, are there any process backlogs available? Anyone having experiences of this? I

/ Johan Nordin