, , , , , , , , ,

Dear practitioners,

From the very first time that I found myself representing change and implementing new approaches within an organization that found itself in the wrong end of town, most often times by taking too many wrong turns when it comes to software development practices and processes. In the center of it is the mother of issues, Graphic Design.

Oh yes, the obligatory activity that many organization put at the front of the bus and often times let’s it drive. Lets get one thing clear before we talk more about this, Design does not drive function. Function drives not only design, but the very development of the software which gives it value. The one mistake that most departments make is to simply let themselves believe that they require huge amount of time to work eccentric global designs that will make a product revolutionary. They will work at this design with personnel that have no idea of how this can actually translate into functionnal pieces of software.

Recently, a lot of focus has been put in understanding the real cost of technical debt and it’s impact on delivery. What do you figure a design which ends up being X times more difficult to integrate is? If not debt, then it is a big waste of time and money if the very work which is suppose to be integrated along with the function is either too complex to fit or does not align with the very essence of the requirement. One comment, which truly has come up very often, is how do you expect us to get a design done within a Sprint. To my astonishment, alot of people believe that there is no way it can be done. That it is simply theoritical. I get “Well yes, in theory, but you know.. in reality”, since when did we make theoritical software. As you know, this leads to a subject which I have covered many times, change management. For too long, Design people have simply behaved by working ahead and throwing their work over the fence to development teams and go on their merry way. The us vs them mentality has to stop to gain any kind of ground when it comes to be able to integrate design elements within software increments. Teams must be composed of people with the abilities to complement designers. This is part 1 of a series because I will be implementing changes that covers this topic in the very near future and I shall let you know of our progress.

In closing, alot of “ink” has been spilled on this subject and like I have said before, most look for a magical method for what ails them. Remember that no one solution works if it is not an exact match with your context. It would be like doctors giving a prognosis over the web and referring all patients to it. Scrum is a very powerful tool. Use it to learn.

Thanks, PS 🙂