pbielicki's blog

Half-dead project saved! Thank you - Direct Communication

May 21, 2009 by Przemysław Bielicki

Picture (c) Przemyslaw Bielicki

In my previous post I shortly described the half-dead project in an over-waterfall company me and my team had to save three months before production. In this part I will show you how direct (instead of discrete) communication with customer or good Product Owner in general can help saving almost dead projects.

As I described earlier me and my team had a lot of problems with the systems we had to integrate - technical issues were present but they were not dominant, even taking into account the fact that the team was not experienced in .NET and T-SQL stuff.

Direct communication as a half-dead project saver: When you start in an over-waterfall company

April 30, 2009 by Przemysław Bielicki

Picture courtesy of clagnut@flickr

At the end of year 2008 our team was given a project that was critical from the $$ point of view. We had to deliver the project by the end of March 2009 in order to avoid huge fees from our customer. The problem was that the project we got was being developed by different team in different location and the quality of the existing solution was at least questionable. It turned out that the whole old team left the company and our small commando squad had to save the day. I just have to mention that the company we all worked for was a pure-waterfall monster.

You know, agile books are fun to read, but how do you start it if you happen to be a developer in a pure waterfall company on an impossible project? I went through it and going to show what worked well for us. I will tell how we were able to get an impossible project apply the agile principles and survive.

Everybody Needs ... Unit Tests

February 5, 2009 by Przemysław Bielicki

Picture courtesy of Lotus72@flickr

... please remember people, no matter who you are, and whatever you do to live, thrive and survive, there are still some things that make us all the same: you, me, him, them - everybody, everybody! - this is a fragment of Blues Brothers' "Everybody Need Somebody" song. Nothing to do with software development but when you change the next line of this song from "Everybody needs somebody" to "Everybody needs Unit Tests" it becomes closer to software development.

I intentionally used lyrics of this song to keep everyone's attention (just a little bit) to this post. If you are familiar with TDD and unit test your code you can disregard it - I'd like to address this post to all software engineers/developers/programmers/etc. that DO NOT unit test their code.

In this post I will try (again) to convince all software developers that still don't unit test their code that it's right thing to do and it's damn simple.

Seven Principles of Lean Software Development

January 20, 2009 by Przemysław Bielicki

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:

Seven Principles of Lean Software Development - Eliminate Waste

January 9, 2009 by Przemysław Bielicki

Picture courtesy of Phil Romans@flickr

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.

Year 2008 in a nutshell

December 22, 2008 by Przemysław Bielicki

Picture courtesy of foxypar4@flickr

Christmas and New Year is coming so it's time for some summary. I've never done this before but this year was quite awesome and I have something to be proud and loud.

Let's start from January when I moved from my hometown to the glamorous French Riviera i.e Cote d'azur (yes, the sea here is pretty much azure).

I accomplished some cool stuff at work and one that I can share with you is the new generation hotel search engine - Wallaby (which is working but still in beta phase).

Seven Principles of Lean Software Development - Create Knowledge

December 11, 2008 by Przemysław Bielicki

Picture courtesy of J.C.Rojas@flickr

"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.

Seven Principles of Lean Software Development - Build Quality In

December 4, 2008 by Przemysław Bielicki

Picture courtesy of WayTru@flickr

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.

"I know it doesn't work but it's done" - a story about the definition of done

November 28, 2008 by Przemysław Bielicki

Picture courtesy of orinrobertjohn@flickr

Some time ago I was talking to engineers responsible for some part of the software and I was asking when they will be ready for production. In other words I asked them when their features will be ready. They told me that they are ready now. What was my surprise when I tried to test their software and discovered that about 50% of cases were not working at all. So I asked them why they told me that they are "done" when they haven't even implemented half of the planned features? They answered me: "We know it doesn't work but it's done - we implemented something so it's done. Now we have to work on quality i.e. implement rest of the features."

When I heard this I think I might have looked like the lady from the picture. I couldn't believe someone can think like this - if we implement one use case out of one hundred we can consider the project done? The rest is the "quality"? I don't think so.

In this post I'll try to explain once again what is definition of done and why it's so important to have the same definition at least among all the people involved in the development of a single project.

Developers Aren't Gonna Read It

November 20, 2008 by Przemysław Bielicki

Picture courtesy of austinevan@flickr

Developers are the customers - from time to time. They are the customers for product definition/specification team that is preparing technical specification documents. It doesn't really matter whether you work in an agile or non-agile environment - I'm sure you have some technical documentation and the main goal of it is to answer developers' questions on technical issues (e.g. how to configure some components to work with others, how to map fields from GUI forms to XML message, etc.) It also helps test or QA team to prepare acceptance tests and to verify whether what developers implemented is what was specified (I know it stinks a bit the waterfall but stay tuned - I will say something about agile documentation soon).

I would suggest you reading an article on TAGRI (They Aren't Gonna Read It) by Scott W. Ambler - it's really great. And in my post I'm going to give you real-life example from what I experienced regarding documentation. I will share with you my opinions of what kind of documentation sucks and what documents are really cool and useful (btw. my dream documentation is the one with which I'm able to find accurate information of my interest quickly and be able to put this information into my head in less than 10 minutes - the picture you see is a total contradiction of my dream - it's a waterfall process).