Development is innovation

I think one problem for software development organisations is the idea that the purpose of the process is to scale up development activities and remove the dependency to the individual instead of using the potential of the individual.

I see software development as an highly innovative process,  because you are about to solve a problem that has not been solved before (at least as far as you know when you are facing the problem). If you knew of a solution allready available, then no development should most likely take place you would just use what is allready available.

Therefore, I would suggest that we search for guidence in areas where innovation and creativity take place.

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!

Defining Technical Debt

Introducing technical debt into the code base is waste. Yes, but what do we mean with technical debt. In this post I will try to aggregate and define what meaning those words has to me.

Hypothesis: Technical debit is when you are making short term decisions on the price of long term quality.

Why do I like the term?
I like the words Technical Debt because it illustrates the balance of making short and long term decisions. You can make short term decisions, but if you are increasing your debt, then sooner or later you will have to pay your debts. And if you have built up a large pile debts, then the rent you pay on the debts have large impact on what you do today.

isn’t Technical Debt another word for…?
Violating non-functional requirements, Writing legacy code,Making systems not maintainable, etc…?

Yes, I think so, but I don’t really care, because what I like is that there is something with just two words, that can create a thought and content placeholder for a really important concept in software development.

What is Technical Debt then?

Looking on things from the Cooperative game perspective written by Alistair Cockburn, I would say that it is when you are not focusing on your current game and not creates an advantagous position for the next game.

Further questions

When you are making short term decisions that have impact on other systems, is that also technical debt? Or, is there something that is called enterprise debt? Well, I think this might be a dangerous path to walk here.

Is the words making things too simple? Are we trying to include too much comlicated issues in just two words?

References
– I think Alistair Cockburn describes it quite well in the Cooperative Game.

Hmm, the discussion relating to this topic is not finished…

Are you Lean, are you becoming Lean or do you do Lean things?

Is Lean something you are or something you do?

From my perspective (what other point can I make???) is Lean something we are trying to be. I think (and hope) that there will never be a time when I will answer a question with “Well, we have implemented Lean Software Development and boy, we are really Lean….and Agile!”. Instead, I really would say that yes, we are today implementing the ideas and thoughts of Lean Software Development and if you ask me in ten years from now, I will most likely answer the same – unless working with something else or the need for improving the business is gone…

I think that the only way to tell how successfull we are in implementing Lean or Agile is to look on how good we are in delivering business value to our customers… quickly, repeatedly and reliably…every time!

Cheers!
/ Johan

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.

A few notes on Standards and Guidelines

Here is my current view on guidelines and standards (aggregated from Lean, experiences and other sources):

• Current best way of working, No such thing as “Best practice” because that only kills motivation
• I don’t want guidelines that prevent people from thinking
• Try to make them executable

When do we use guidelines?
1) When new to a domain
2) As a basis for improvment (where are we now and where is our target condition)
3) When you don’t want to make a decision and want to be “safe”

The problem with guidelines is that as soon as you are familiar to the domain of the problem, you will most likely not read any guidelines on the subject. The value from written content will be minimal, because you will not read it. The questions is also how much attention you will have on new guidlines that differs from your current way of working?

That is why I really like the idea of making guidelines executable, so when you are not following the current best way of working, you will be notified.

What kind of guidelines are not possible to make executable? How much effort is it worth creating them?

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