You are currently browsing the category archive for the ‘Lean’ category.
The future of lean is exciting. Its tools for eliminating waste and for increasing value as customers define it are being enhanced by huge gains in the volume and quality of the information companies can gather about customer behavior, the value of the marketing insights that can be integrated with operations, and the sophistication of the psychological insights brought to bear on the customer’s needs and desires. These advances bring new meaning to the classic lean maxim “learning to see.”
- Who are your customers?
- What do they ask you for?
- What do you do to the requests?
- And where do they go when you are finished with them?
Limiting the number of projects a team is working on – making the team do less – does not have to reduce productivity and can actually deliver more
when we look around at the companies who are doing well, it can be hard to see the rhyme or reason of the decisions that led to that success. Take Apple and the work it put into building a technology platform on which hundreds of thousands of independent developers could create apps and offer them to Apple’s customers. Or take Salesforce.com and its willingness to have self-organizing development teams continuously tweaking code, even though, with a global system serving more than two million subscribers, the risks of introducing errors into its 30 million lines of code would seem to present compelling reasons not to. (Drawing on the software development practices known as Agile, Scrum, and XP, the teams work in short, iterative cycles of test-driven development with direct customer feedback as the work proceeds.)
In fact, these companies are not behaving chaotically. They are acting according to a rethinking of the rules to suit today’s business conditions, and learning new heuristics based on their successes.
People turn estimates into targets. Meeting the target becomes the de facto goal and the de facto method. Meeting needs fades in priority
IT people is often scared when I say that I don’t like the traditional testing phase in IT projects.
I understand, it’s so relaxing to know that you have a bunch of people to blame when projects go the wrong way: “we did 3 month of testing, we really couldn’t do more to save this project!”.
And if it’s not the testing team, you can always blame the requirements team for gathering them badly. But this is another story, another post :). Let’s get back to testing.
What I generally don’t like about testing is that you do some operations based on … what the system is designed to do. Someone writes a requirement, someone (else) writes one or more test cases to prove it, someone (else) writes some code and finally someone (else) reads the test case and uses the system giving his interpretation of the behavior … giving a GO/NO GO.
Should I explain why I feel uncomfortable? I hope not but let me add an unobvious thing: where is reality in this long chain? Who’s in charge of saying if the system is doing what is needed and not what someone (else) thinks it should be doing?
Scary, isn’t it?
We will talk about a new development technique called WDD or Worries Driven Development.
You might know another couple of *DD techniques: TDD and DDD but they are by far less powerful than WDD.
TDD or Test Driven Development has been invented by Ken Beck (@kentbeck). As Wikipedia states “is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards”.
DDD or Domain Drive Design is a little more recent, especially it’s hype, and as Wikipedia says “is an approach to develop software for complex needs by connecting the implementation to an evolving model.The premise of domain-driven design is the following: Placing the project’s primary focus on the core domain and domain logic; Basing complex designs on a model of the domain; Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.” In Italy Alberto Barndolini (@ziobrando) is really good at it!
WDD is more powerful because it works at a deeper level. It acts at the level of motivations. We tend to do what we do for one of two reasons: to seek pleasure or to avoid pain.
Now our culture tend to push us to the ‘avoid pain’ side so we tend to use it more often as a motivation to do what we do. So what’s more relieving than solving a problem to ‘avoid pain’?
That’s where WDD come from: we do what worries us. Or better we do, schedule, put in priority what can have consequences that can worry us.
So the algorithm is: if you don’t have it, create a problem, throw it in the future, communicate it so that everybody can be worried. Now you are ready to make a lot of overtime to solve it to ‘avoid pain’.
The secret? WDD is not that new: it is quite often used as a primary development paradigm in many offices of medium-big corporations. And it works …. maybe.
Back in 2001, traditional management had the idea that if everything was documented, things would work out fine.
Three reasons to read this article:
- because in 2012 90% of management DO have the idea that full documentation means “it will work fine“
- because it’s an interesting article about agility and beyond (adding some lean startup concepts too)
- because most of the stuff that you read comes from Kent Beck and you should read everything from Kent. PERIOD.
Tell us what you think
Once Kent Beck wrote:
So if there is value in making good decisions, there is even more value in taking daily those decisions that improve our learning experience.
Let’s face it, working in an Agile fashion is hard. It requires paying attention to what you’re doing and the results of that. It requires thinking and making choices. It requires honoring the thoughts and feelings of those around you. None of this is easy stuff.
What’s your thought?