Milestones not Millstones

Setting goals and hitting them. Important. But, more critical, is building momentum and moving forward, making progress. Milestones are goals that mark significant events within a project. These figurative milestones allow a team to gauge their progress toward ultimate project completion just as the literal milestones allow travelers to judge physical progress on a journey. Milestones are a tool for decomposing a large goal into smaller, more manageable units. They provide a guidance that allow teams to measure and celebrate progress.

A millstone is a heavy stone weight that is used to grind things into dust. In projects, a milestone becomes a millstone when it fails to generate healthy tension and instead becomes a source of anxiety and unproductive stress. Millstones create mental barriers to progress and establish negative patterns of thought and behavior. They push teams back rather than pull teams forward.

Managing a project is about setting-up challenging, but achievable milestones. Failure to reach a milestone should be viewed as an opportunity to improve the process, to recognize and remove impediments, and to reconsider potentially erroneous assumptions. Sometime, however, milestones become millstones—they may drag behind a project team and impede progress. When your goals become demotivating, they must be realigned, redesigned, or simply purged.

Project Decomposition Terms

There are a least a dozen different terms in broad use for very similar concepts. We are trying to focus our own nomenclature to give us a more consistent presentation to each other and to the world. Using the same terms to mean precisely the same things, we lower to barrier to introducing consultants to projects—the uncertainty is reduced because the form is familiar like sitting in your favorite chair.

Project decomposition is an important principle for surviving complex software projects. It allows planning in smaller, more manageable chunks of time and functionality. It creates regular milestones that make progress tangible. It enforces rigor to finish and finalize in smaller, less taxing increments. Do it, you will like it.

Iterations are temporary build milestones:

• 1-2 weeks of effort, design/build/unit test
  
• Demo-ready
  
• Increment your patch-level RuleSet versions for each
  

Slivers are temporary build artifacts:

• 6-8 weeks of effort [3-4 iterations], design/build
  
• Smaller, individually-useful, 'partial' applications
  
• Tested [2 week], patched and documented
  
• Production-ready, but not necessarily deployed
  
• Increment your minor-level RuleSet versions for each
  

 

Modules are a permanent design elements:

• Technical vs. Functional
  
• Reusable and Individually testable
  

Releases are a temporary deployment artifacts:

• One or more Slivers, though ideally no more than 2
  
• Practical selection based on deployment windows
  
• Production visible, so involved transition activities such as training and support
  
• Increment you major-level RuleSet version for each
  

Applications are permanent production artifacts

• Increment your Application record version for each
  

 

 
 

 
 

  

Creative Destruction and Taking Steps

Two key concepts from my "10 Guiding Principles for Surviving Complex Projects" post:

• Taking steps
  
  • A step in wrong direction is better than no steps in the perfect direction. Progress is more valued than perfection.
    
• Decriminalizing change:
  
  • Embrace creative destruction. Learning quickly is better than planning perfectly.
    
    

I recently had the chance to speak to a project team on these related topics. Together, they encapsulate crucial expectations about the performance of all Knowledge Warriors. Faced with an unclear directive and lack of specific direction, you must take steps to further the task. This doesn't mean that you should not seek additional clarity. You should try and try again. If clarity is not forth-coming, you should use best judgment. Pick an approach or direction: test that approach. We will never punish someone for taking steps—we can explore and improve your judgments, we can decide to reverse or redirect, but we cannot criticize motion in the face of uncertainty. That is always praise-worthy.

Implicit in this contract between management and staff is the open acceptance of creative destruction. Creative destruction means that 'rework' is not indicative of failure. Rework is a natural result of our process that encourages experimentation, learning by doing, and forward momentum. From kindergarten to corporation, fear of failure has been instilled. The wrong answer is punished. Not here. Wrong answers are expected and encouraged in the spirit of inquiry and step taking. This is what makes us great. Explore and be wrong. Revise and get right. Test and share. Expect to have some of your best work 'thrown away'. Expect to learn from every step you take. Expect that your managers and your teammates will be disappointed only if you fail to take steps.

Why do we think this is so important? Because we deal in the reduction of uncertainty, the resolution of chaos. Building and preserving forward momentum for a project is critical to vanquishing entropy and injecting clarity. Momentum, forward progress, is always hard to achieve. To stand and await direction is to give hard-won ground to the enemy, chaos. I have seen many great pieces of software languish because a project simply lost momentum. Don't allow it.

Convention over Configuration

"Convention over Configuration is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility." -Convention over Configuration, Wikipedia

A very promising tool in an application designer's toolbox is a concept known as Convention over Configuration (CoC). It is related to the concept of Design by Convention (D by C) in that the "people" involved in D by C are end-users where CoC concerns developers. Addressing the conventions used by developers is generally what is involved in the creation of modern Software Frameworks. Probably the framework that most openly embraces CoC, and is my favorite technical movement born this century, is Ruby on Rails (RoR). RoR is a web-application development framework based on the Ruby programming language.

By decreasing the scope of change through the application of reasonable defaults, we define a box within which a designer/developer can truly thrive. They thrive because we reduce the cognitive load imposed by the approach allowing more crucial mental space for the complexities of the problem/solution. Cognitive load theory, in simple terms, says that people have a finite amount of mental space available for processing of tasks. To make people more effective, we must help them optimize their mental space (ie. reduce the cognitive load).

What does it mean to us? Convention over Configuration means that we follow a small set of well defined 'rules' or conventions that allow us to make simplifying assumptions about a solution space.

Putting CoC into Practice

Making your Conventions clear and malleable using the 5.3 feature called Declare Pages and the concept of DRY (Don't Repeat Yourself).

Rule-Declare-Page sets up a rule that will create a special sort of clipboard page that all requestors on a node will share.

Create a class to hold properties relating to the Conventions that your application requires.

An activity that simply uses a model to populate the page will be used to "load" the page to the clipboard when accessed the first time.

The model sets the values to match your defined constants to drive your Conventions.

To use the Convention constants, put a reference to Declare_Conventions - IQ-Convention into your Pages and Classes and then refer to its properties as usual.

.pyAssignedOperator = Declare_Conventions.WorkBasketPrefix + .ProductCode + Declare_Conventions.WorkBasketPostfix

On the clipboard, you can see the Declare_Conventions page contains the properties and values that you defined.

After the activities run, you can see that the values have been used in the concatenated Property-Set.

What Conventions are set in this example?

1. All WorkBasket names will be the ProductCode with the value "@IBX" appended.
2. All Skill names will be the HoldCode value with the value "ITS_MHSHC_" prepended.

Now that we can make the Convention and know how to utilize the conventions, what are the conventions that drive the design of your current system?