I have been thinking about the relationships we all experience to the work product we are responsible for. The degree of authority we express over some work product, the degree of autonomy we have over some work processes, and the degree of responsibility we are assigned for that work product dictate our role or relationship with that product, and potentially can affect our productivity and job satisfaction.Continue Reading
Articles from June 2012
Pragma
Do you ever feel like the organization around you has lost the plot? That we (collectively) no longer remember why we do all of the things that we are required to do? That we spend an inordinate amount of time on activities that don’t really help.
It is very easy for processes and procedures to transform from pragma to organizational dogma. We forget (did we ever really know?) why we started doing something, and pretty soon, “That’s just the way we do it here.” And pretty soon after that, anyone who questions it “just doesn’t get it.”
The problem is this: When we become dogmatic, we stop reflecting on the goal, and simply do the practice not regarding whether we are achieving the goal, or whether the practice is effective at achieving the goal. When the practice no longer helps us achieve the goal, or gets in the way of achieving the goal, it needs to be adjusted, optioned, or eliminated.
The remainder of this post will explore why things go from pragma to dogma, and how we adjust, option, and eliminate ineffective practices.Continue Reading
One Thing At A Time
This post is about things that can go wrong on an agile software delivery team. One thing that I have learned over years of software delivery is that you have to finish something, sometime. You have to deliver a working capability, feature, or story. When you finish an iteration with no working stories – you are doing something wrong; very, very wrong.
One working feature is better than 5 half working ones. One of the problems is our multi-layered systems. Back in the day, we had a programming language and maybe a database with a library. Then databases got their own language and I had to know how to stitch SQL into my COBOL or C code. Then we became object oriented so we had to translate data in a database to data in objects. Then we had PC’s, networks and servers and distributed processing. Then we had graphical user interfaces, and the libraries and patterns used to manage them. Ultimately we have evolved patterns for implementing software in many physical and logical layers each requiring knowledge of different language and object constructs and patterns. On a recent we application built, I counted 17 distinct technology skill sets required to complete the project.
One problem with modern layered systems is that it is becoming more and more rare, to have a single individual who is skilled at design and implementation across all layers so that he can design and build a complete software capability unassisted. But this post is about a different problem.Continue Reading