Framed Home under construction

Agile Software Development and the House Metaphor

Posted on by TheSocraticPM

Earlier this summer, I had the opportunity to speak to a group of lawyers regarding Agile Software Development. This was a joint panel discussion with a couple of subject matter experts who were there to discuss the pros of Open Source software. While my performance left much to be desired, the open source subject matter experts were phenomenal in their explanation and use of metaphors. Some of the metaphors used were:

  • The German Enigma machine when discussing the concept of concealing the “how” versus concealing the “what”
  • A door lock when discussing the availability of how a lock works versus the concealment of the “key” which unlocks the lock
  • The comparison of a car with the hood sealed shut when discussing closed software versus a car with the hood that opens when discussing open software

While the subject matters experts used several other metaphors, one that resonate with me from an Agile perspective was the metaphor of a house.

The Open Source SMEs used the metaphor in terms of the public nature of the architectural plans of a house. It is as follows, when building a house on spec, the plans for that house are filed with the County where the house will be built. While the plans are owned by the homeowner, they are available and most times publicly. The public nature of the plans do not prevent the homeowner from building the home. Further, while the plans are public they do not limit the ability of the homeowner to secure and insure the belongs in the house.

So what does this have to do with Agile Program Management?

I regret not leveraging this metaphor further for Agile software development. Using Agile software development is similar to being able to live and test each room of a house as it is being built. It also allows the homeowner to prioritize the building of the rooms of a house based on the homeowner’s priority but respective of the infrastructure necessary to support the rooms. For example, if the homeowner prioritizes the master bedroom as the most important room, the builder will build the infrastructure necessary to support that room first. This may include installing the plumbing for the en suite and installing the HVAC for the heating and cooling. It may also include the installation of steps and the minimal framing of lower levels to support the master bedroom, if it were on the second floor.

The house metaphor was also appropriate as it similarly fixes cost and time as an agile software development project does. In most cases when building a house, the homeowner is bound by time for delivery and a budget. The fixtures and elements (e.g. the scope) of the house are changeable based upon the homeowner’s value selection. If a homeowner does not have the budget for that third bathroom, it will not be delivered in the scheduled timeline but a later rehab may take place. Again, this is based upon the homeowners relative value of maybe adding a walk-in closet.

The house metaphor was a great metaphor to explain the iterative and value based nature of agile software development while considering the architectural components required to deliver each room of the house. I regret not taking the opportunity to use it when it was presented.

The Chicken and Egg Dilemma of an Agile Transformation

Posted on by TheSocraticPM

As more organizations attempt to transform from traditional management practices to more agile, they are confronted with a Chicken and Egg causality dilemma.

Chicken: Organizations that choose the “way of the Chicken,” want to select an agile framework and implement it in their organization. The majority of organizations attempt to take an agile framework/methodology such as Scrum, Kanban, or XP “off-the-shelf” and implement it. These organizations will identify the appropriate resources, train only them, and expect agile to just happen. According to Dr. Ahmed Sidky these organizations want to “Do Agile.” In my opinion, they want the Chicken, fully grown and ready to lay more “Agile eggs”.

Egg: Those on the egg side of the dilemma want to ingrain an understanding of Agile within the organization. These organizations will commit to training executives and other stakeholders across the organization in Agile in order to create a baseline understanding and taxonomy. Per Dr. Sidky, these organizations want to “Be Agile.” In my opinion these organizations are laying Agile eggs unsure of exactly what the Chicken will turnout to be. These organizations are not sure if they are going to hatch a Rhode Island Red, a Leghorn, a Plymouth Rock, or some new breed of chicken. They believe that with enough care and feeding they will end up with a chicken.

In my experience the “way of the chicken” is not a long-term approach to transforming an organization toward agility. The organization may have a few successful agile projects but there will be a reliance on a few heroes to pull the projects over the finish line. The agile projects will be challenged with organizational stovepipes and fiefdoms. In a lot of cases resources are not fully allocated to the project and the product owner is not fully empowered. Worse yet, there are different understandings and expectations of Agile. For example, I consultant an organization where the CIO repeatedly press his PMO to eliminate all documentation for his agile projects because he believed Agile meant “no documentation.” Meanwhile the CIO refused to purchase any tooling that would support the reduction of documentation he so desired.

Laying “Agile Eggs” is the best approach I have experienced. Training executives and stakeholders brings about a common understanding of Agile as cultural and management paradigm shift. The organization may realize that integrating agile into the organization may require a change in the structure of the organization. Organizations that have traditional hierarchical structures may soon realize that they need to organize around portfolios of products and services.

As you can see I prefer the egg side of the dilemma over the chicken side. This solely based upon my experience. I believe agile is a way of being rather than an off-the-shelf practice. I believe management must change from our traditional management paradigm which is based in scientific management to a more adaptive and sensing paradigm. But these are topics for future posts. I guess you can say, I believe we should, “lay more agile eggs.”

Can you create a template for that?

Posted on by TheSocraticPM

 

As a project management consultant I sometimes get frustrated, even angry when a client quickly asks, “Can you give me a template for that?”

My frustration stems from my gut feeling that my client only wants the template to hasten the completion of their task without really understanding the reasoning for the artifact the template represents. This frustration is increased as I consider myself an Agilist and only want to create documentation when it is necessary. My Agilist side says, “No, I will not create that template! You haven’t determined whether you really need that artifact.”

This is when I must get off my “high horse” and get over myself. Templates have purpose.

  • Templates are time saving tools. Yes, my client might just want to save a little time.
  • Templates can improve the quality of communication.
  • Templates are containers of required information. They can take the guess work out of what readers or project stakeholders require of the particular artifact.
  • Templates provide for consistency of information. Readers of the artifact will have a good feel for where specific information is located because the information is consistently presented from project to project.

I also need to come to terms that sometimes my clients are not as engaged and just do not care about the project management disciplines as much as I do. My clients probably could care even less about agility in project management. Most of my clients are focused on delivering and successful delivery of the project outcomes.

Bottom line templates have a purpose in the world of project management. Develop them and incorporate them in your project management life cycle. BUT use good judgement in developing and providing templates. Do not “templatize” everything.

And just because you provide a template does not mean that you have to create a highly customized template down to the level 3 Header. This becomes a form and will most defiantly remove the thinking from the author.