Getting Done the Lean Way

Something I’ve been thinking about lately, as I’ve been going through reams of paper on lean, kanban, kaizen and Toyota Production system concepts, is how the definition of done differs from that we are used to in Scrum.

In Scrum, the product owner gets with the rest of the team and the come up with a definition of done for the particular project.  What done means is essentially the responsibility of the product owner, but its an exercise done by the entire team.  What done means on one project might not be the same definition of done for another project you work on.  This is an allowance in Scrum.

In lean, I think I’ve decided that all lean projects have the same definition of done.  Lean is about value, flow and waste elimination, in that order.  With value being the primary focus of any lean organization, the word done must correlates to value.  Thus done can be defined partially as ROI if you want to look at it that way, but something is done the moment value is achieved.  This is the reason why waste elimination is such an important part of lean concepts: its a way to reduce the time it takes to get something done, thus reducing time it takes to provide value.

Naturally a product evolves over time, but in many cases, there is an immense amount of value in getting a product out to market, even though its not your final vision.  This is true for every product I can think of.  You think Toyota waited to put out the Camry until they thought it was perfect?  Of course not.  However, the value in getting the car to market given the state of everything, made sense and provided a lot of value.  We view things in software a bit differently, especially in non-Agile circles, but the same holds true.  Lean software’s doneness is the moment it can provide value to its customers/owners.

As the people who write software, we might not always be aware of the value a product provides to its company, thus we might not understand why certain feature sets are created before others and it might not make sense to us.  I’ve never been an end consumer of any software I’ve been a part of writing in 15 years.  HR, PR, marketing, accounting, etc.  These are the people who are most likely to understand the value to its highest degree.  Its our job to do work, evaluate cycles, make changes to eliminate waste and continuously improve our processes and reduce the time it takes to provide value.

Posted in Agile, Alt.Net, Lean, Scrum | 4 Comments

There is too much money to be made in software development

Its true.  Too much money is available to IT.

As a business with too much money assigned to an IT budget, you’re allowed to have teams completely fail, miserably, and when they do, you just throw more money at it.  Lack of money isn’t the problem.  The failures will still exist.

Mediocre developers can make too much money.  Enough money so that there is no incentive for them to be better at their jobs.  To improve.  They are satisfied with the amount of salary they receive, and do not feel compelled to improve as the amount of money they would receive in addition isn’t enough to justify the amount of effort required to exist in a zone of software excellence.

The market is saturated with mediocrity, and at a high price.  I’m not going to start repeating myself here; those several sentences above pretty much say it all.  Too many developers don’t have incentive to improve their processes and abilities because they are overly compensated for their skills.  Do they deliver some sort of business value, eventually?  Probably.  And too many of them do it as consultants, write shitty software, deliver working software that nobody in the world can come in and understand what the hell is going on in the code.  Business are blind to this aspect of the software development lifecycle: solubility (thanks Scott) and maintainability.  Make it work, at any cost, and move on to another paycheck.  This is the world we, as software developers, are living in.

What is the rememdy?  How to we improve this?  How do excellent software developers make businesses wake up and take notice to the wool over their eyes?  Do I write awesome software?  Certainly not.  There are occasions where some of the decisions I make should be exposed for what they are: poor decisions.  I do what I can to expose them and make them visible so that all involved can learn from my mistakes.  Perhaps I don’t do enough of this, because, after all, my job and reputation is at stake.  At the same time, I feel a moral responsibility to expose myself.  I need to improve, but the software community as a whole needs to improve even more.

Posted in .Net Development, Agile, Alt.Net, Featured, Generalities | 69 Comments

Are you a problem solver or a developer?

I had this conversation with some friends on Twitter about a month ago and have been thinkinng about it ever since.  We are all professionals, but professional what?

I have come to the conclusion that I am a problem solver.  That’s my business.  Whether its process management, software architecture, personal growth for my development team or trying to keep my daughter from stealing my son’s toys, I solve problems.  Software development is my tool (except for the stealing part.  I use my daddy voice for that).

One thing I have learned from BDD is that developers spend too much time thinking about technical implementation details rather than the problem at hand itself.  I am continuously working with my current team to get them all to adjust to this way of thinking: think about the problem.  What are we trying to do?  We’re not trying to write software, we are trying to provide value to our customer, and we achieve that through software.  Adopting the context/specification style of testing has helped me evolve even more into a digging into a deeper understanding of what the problem really is, what context does the problem apply to, and what are the specifications that are proof to show that a solution can be demonstrated?  You MUST think about these issues before writing any code, and too many developers just want to code without fully understanding what the problem is.  ONLY when you fully understand the problem, can duplicate the problem and demostrate it with specifications, can you start thinking about technical implementation.  Naturally, you have to have some sort of roadmap, an idea for system architecture, think about non-functional requirements, and that’s all expected and necessary. But when it comes down to coding a piece of behavior into a system, too many developers are still just jumping in and coding.  Even when writing unit tests, developers are thinking about the techinical aspects of the system and often write poor unit tests.  I’ve been there.  This is why I feel TDD is an ancient and outdated craft.  TDD does not do enough to force developers to really focus on the problem and gain a full understanding of it prior to coding.  I feel BDD helps achieve this.

I haven’t posted anything on what I’m doing with BDD because you can search CodeBetter for it and find information from several of the bloggers, all of whom I’ve spent a considerable amount of time with to help me evolve to be a better problem solver, by way of writing software.

We need to focus on the problem at hand, and let the technical details and implementations evolve from specifications and that demonstrate the problem.  C# is easy.  Correctly solving the problem your customer is having and delivering the appropriate behavior is much more difficult, so there is where your time needs to be spent: understanding the problem.  Once you fully understand what you are trying to deliver and have specifications within context to demonstrate this, the technical solution will be clear, simple and right in front of you.  Let it evolve from that.  The technical implementation is secondary to the understanding of the solution.

Posted in Agile, Featured | 20 Comments

LOL You have got to see this

This was just WAY TOO FUNNY to pass up sharing with everybody! Sorry for the link post, but I couldn’t stop myself.  Check out the name of the ship!

Posted in Generalities | 7 Comments

How do you clean up the files in a project quickly?

Put your hands on your keyboard, don’t touch the mouse.

CTRL-ALT-L; Down Arrow (to a file), Enter, CTRL-ALT-F, Enter, (F12, Alt-Enter, Enter (repeat all necessary loops)), CTRL-ALT-F, Enter, CTRL-S, CTRL-F4

Repeat until you reach the end of the file list.  *note* you have to have Resharper.  If you don’t, shame on you.  Your job is harder than mine.

Update:  This is using IntelliJ mappings.  The key sequences are as follows:

CTLR-ALT-L – move from editor window to solution explorer.

CTRL-ALT-F – reformat code

F12 – move to next error/problem/issue

ALT-ENTER – suggestions for fixing issue

CTRL-S – save the file

CTRL-F4 – close the fil

Posted in Generalities, OOP | 14 Comments