Category: management
Photo (c) Janusz Gorycki
Donald Knuth's famous book is titled "The Art of Computer Programming". Take it from one of the "gods" of our profession - software development is "The Art"! More precisely though, it is an act of creation. Nothing surprising about it if you take a closer look: suffice it to say that no two computer programs should be the same. If you find yourself coding the some thing twice, you are doing something very wrong. Also, computer programs do not really have any material form to speak of, other than a bunch of electrons stuck in a chip of silicon - they are quite literally - pure manifestation of someone's ideas.
Let me put this in an eye-catching one-liner to focus everyones attention: software is not manufactured in a scientifically controlled way - it is created
This simple (and pretty obvious) observation does not imply that programming is a more "noble" activity then, say, sweeping floors, bookkeeping or assembling cars in the factory - the value of ones work should be judged solely by the results and not by the nature of the task. It does however have quite a few interesting and very often neglected consequences - and any software project manager (agile or otherwise) would be better off rememebering them.
Bookmark/Search this post with:
Lean Software Development has its roots in Toyota Production System and it helps software organizations optimize their processes and production methods in order to deliver their products to the market much faster and with better quality. Lean movement can be considered as a new development method that tries to identify and eradicate all problems and "disabilities" of old methodologies like Waterfall. Lean puts main focus on people and communication - if people who produce the software are respected and they communicate efficiently, it is more likely that they will deliver good product and the final customer will be satisfied.
Lean Software Development subsequently gave birth to Agile Software Development methods and its main branches like Scrum or Crystal Clear. For many people who know the subject Agile is just another word for Lean or Lightweight.
In one of the most popular books on Lean subject, namely "Implementing Lean Software Development - from Concept to Cash", Mary and Tom Poppendieck explain how to implement Lean by following seven principles - principles that are some kind of Lean commandments:
Bookmark/Search this post with:
Peter Stevens in his newest post advices how to deal with current crisis using Lean methodologies. One of his advice is to eliminate wastes, not costs. I totally agree with it, more so it is one of the most important (at least for me) principles of Lean Software Development.
Software development organizations should always strive to produce the best products and to deliver only features that are of paramount importance to their customers. They should always try to develop those 20% of functionalities that represent 80% of the value. This need is more vivid and desired during such global business conditions. This could apply to all types of enterprises - you should eliminate all unnecessary steps and waiting periods; you should strive to get the value as soon as possible and to get only pure value without any waste.
In this post I will try to explain "Eliminate Waste" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
Around the world, companies are challenged by the financial crisis. Companies face declining revenue and fixed costs. Lean, Agile and Scrum help your company at all levels to focus on doing the right things, like creating value for your customer and eliminating wasted cost and effort, to get you company back to profitability. Lean, Agile and Scrum help you focus on getting the right Vision, Values and Execution to meet challenging times. Now is the time to start the discussion with your top management.
Bookmark/Search this post with:
"There is no fool like an old fool" says popular international proverb. One of the meanings of this proverb is that people can make mistakes but they should learn from them. You are not a fool if you make mistake but you become one if you make the same mistake again. It simply means that you're not learning.
The same rules apply to the software development teams - it's much easier to work in an environment that encourages you to learn and to create knowledge. Why should you create knowledge? Well, the best way to learn something is to make mistakes by yourself but it wouldn't be wise to let all the engineers invent the wheel all over again. It's much better to teach them about what we already know, what works and what doesn't. It's much better and safer (yet a bit less effective) to learn from someone else's mistakes.
In this post I will try to explain "Create Knowledge" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
I was doing a quick research for this article using Google trying to find arguments standing for the claim that "quality is expensive". I was trying to find some resources saying that care for quality in the early stages of the software projects doesn't make sense and doesn't pay - I find it very difficult and I cannot share with you any reasonable links (maybe except for this one which refers to another post saying that "Quality Sucks").
What does it mean? It means that software people know that quality is very important. Why then quality of software products sucks in more cases than it rocks?
In many big corporations following waterfall model there is a special team named QA (Quality Assurance). This team's responsibility is (not surprisingly) to assure appropriate level of quality in the software product. This is fine, this is perfectly OK, except that QA is considered as a separate activity. This is the "Verification" or "Testing" box in the waterfall model diagram.
The biggest problem with this attitude is that QA team gets the product after it has been implemented and this is the root cause of all evil. QA is considered as something separate - we first do the product and then we care about the quality. This way of thinking is wrong. You should care about quality from the day one, before you write a single line of code.
Software teams should "build quality in" their products and QA should not be considered as a separate activity. Quality Assurance should be constant process of improving the product - QA activities and people should be involved in the development of the product during the development, not after when the developers are moved to another projects or even teams.
In this post I will try to explain "Build Quality In" principle from "Implementing Lean Software Development - from Concept to Cash" book. I will present few practices that will help your team build software with quality built in.
Bookmark/Search this post with:
When software development gods like Paul Graham tell you that people should not be managed, it makes you wonder what we need bosses for. However, after reading You Weren't Meant to Have a Boss I felt the terrible urge to justify my own position as a manager. (And if this post is not going to convince you, then at least it will make me feel better about myself.)
In his post Paul Graham compares employees to lions. He (rightfully) says that lions are not meant to be kept in zoos, and that lions in the wild seem to be "ten times more alive". (He probably meant "ten times more awake," a statement that, according to research, has some truth in it.) Similarly, Paul says, people are not meant to live in big companies. They seem to be "ten times more alive" as entrepreneurs in small startups.
Unfortunately, Paul's analogy is as far away removed from being accurate, as my mother is from being Yahoo's next CEO.
Bookmark/Search this post with:
One of the core XP practices is having a Customer Team Member. It means that development teams have access to the newest information from the customer's side and they know about all changes in the requirements very quickly. Having on-site customer (or customer proxy for commercial products with lots of potential customers) ensures that requests change informally, the process becomes flexible, and saves the cost of formal overhead.
In this post I would like to take another look at this practice. I would like to share with you my thoughts why having a Customer Team Member can help the development team win together with their customer. And I would like to take a "social" view on this practice.
Bookmark/Search this post with:
No matter who you are, where you live and what your job is you have to make decisions. Some decisions are easier, some more difficult (e.g. which way do you want to go on the crossroad with traffic lights from the picture?). But why making decisions is hard? When you make a decision, how do you know it is the right one? What information (if any) you have to posses to make the right decision?
This problem can be referred as "Defer Commitment" principle. Very briefly it tells you to make the decision in the last possible moment when you have enough information to be sure you are going in the right direction. It doesn't tell to you to procrastinate - NOT AT ALL! It's a wrong thinking. It only tells you that you have to wait and collect the data and as soon as you have enough information, make the decision.
In this post I will try to explain "Defer Commitment" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
Lance Armstrong won seven consecutive Tour de France races between years 1999 and 2005. Every year there were 21 individual stages and Lance Armstrong won "only" 4 individual stages in 1999, 1 stage in 2000, 4 stages in 2001, 4 stages in 2002, 2 stages in 2003, 6 stages in 2004 and 2 stages in 2005.
As you can see Lance Armstrong was not focused on winning each stage (quite the opposite). He was focused on winning the whole Tour de France - yet he had to keep close to the head of the race. And when you take a look at time differences between him and the second cyclist in the final classification you will be amazed - they were close to couple of minutes (out of 90 hours of total time!) It means that he was focused on winning the whole race - not to be the best and outstanding cyclist (he was not - I know because I watched many of the stages these years).
Speaking with the lean language Lance Armstrong was Optimizing the Whole - and he succeeded seven times winning the most difficult and exhausting cycling race in the World.
In this post I will try to explain "Optimize the Whole" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle
