Waterfalls!

In our essay, Can Agile (SAFe) Be Interfaced With Waterfall? we identified three major areas that had to be addressed so that a scenario of multiple inter-related programs with different management approaches didn’t turn into a train wreck. Lack of transparency causes misunderstandings and conflict. However, generating transparency has a cost.  Finding the right balance that fits cost and contract constraints is a goal for every complicated program. Generating transparency requires a specific set of behaviors. Several of the most common techniques for generating transparency include: (more…)

 

DSC_0537.JPG

Packages come in all shapes and sizes!

 

Buying a package to perform a major function in an organization is rarely as easy as buying and implementing an app on your smartphone.  Package implementations often include: (more…)

20130515-214218.jpg

Transparency, when combined with goal-driven behaviors, acts as a powerful tool to motivate and guide development teams. Transparent, goal-driven behaviors are an integral component of all software development techniques, particularly when applying Agile techniques. Public, observable commitments are one form of transparent goal-driven behavior.
The process of team members reporting and planning work during the stand-up meeting is an important example of public commitment and transparency. In a well-oiled Agile team, each member of the team accepts work for the day; “taking” the work that is the highest priority or swarming to tasks where help is needed. Everyone knows what everyone else is doing and is free to help guide the process. The act of “taking” the work in public is a tactical form of commitment that brings to bear pressure to perform and support the team. Failure of an individual team member to do what they promised will injure their reputation.
Non-Agile project management techniques do not foster the same level of public commitment that the Scrum stand-up technique creates. Techniques that foster stronger commitment to the task at hand will increase the likelihood that a team will deliver what they promise. This will enhance the reputations of the individual, the team and in the long run the whole IT department. Publicly “taking” work during a stand-up combines transparency and commitment to create motivation.

Fulcrum

Most children and many adults are afraid of the dark because they can not see what exists just outside their vision. Light expands what you can see and typically dispels fear. In projects and organizations if you know what is going to happen or what it is happening it is easier to feel like you are in control. Feeling like we are in control is the light that dispels fear.

Audio Version –  SPaMCAST 121

I originally wrote part of this essay for SPaMCAST 2.  The discussion of how organizations damage themselves by building walls and gates between groups has been driven home by the recent events in Tunisia and Egypt.  While it is difficult to conceive of a Tahrir Square in any corporate office we must be aware that customers, users and employees can’t be shut out of the conversation of direction.  Examples of revolution in business can be as simple as customers walking away, users looking for help outside the organization or employees ignoring directives. Change however is occurring, the self directed team tenant in agile is a reflection of the realization that the gates between management and project teams have to permit bi-directional conversation.  Over specialization and silos lead gates between groups, before building more gates between groups reflect on Tahrir Square and consider different ideas such as cross functional teams.

Impact of Gates on IT Value
Originally Blogged as: Keep the Ship of IT Pointed Towards Delivering Value
Thomas Cagley Jr.

A few weeks ago (now three years later) I attended a lecture by Jared Diamond.  His lecture was in support of his book. Collapse: How Societies Choose to Fail or Succeed (2005).  The ideas in the book concern the anthropology of societies however they are equally relevant to why process improvement programs succeed or fail.  Two of the ideas Dr. Diamond put forth on why societies collapse that are instantly germane to SPI programs are:

  • Elites isolate themselves, and
  • An inability to reassess core values

The fourth definition of term isolate on Answer.com is to ‘to render free of external influence; insulate’.   Organizations that leverage the factory model of IT, create stovepipes, then assigns groups and roles (like SPI) to the stovepipe which causes isolation.  How many cube farms have you been in where a person in one group may sit next to a person in an another group yet neither know each others name unless is stuck to the outside of the cube?   I would suggest that the stovepipe / factory model of IT has supported the creation of insular specialists such as development methodologists, process improvement specialists, project managers and DBAs.  This isolation is in effect a gating / cutting off of decision making groups from those they affect especially when it comes to support groups like process improvement groups, PPQA and project management.  One management theory suggests that specialization in a production environment is more productive.   I would suggest that in scenarios where there are more knowns than unknowns this type of model can be very efficient.  The model of specialization tends to breakdown in scenarios where the unknowns outweigh the knows and a solution requires interdisciplinary knowledge and interaction.  Using a specialist model in the later scenario reduces efficiency, creates unrest and requires management to expend effort to control work rather than on motivation (a directive versus leadership model).   One of the unintended consequences of putting up barriers is the creation of fertile grounds for grass roots movements (such as teams deciding to use agile methods on their own or not to use a specific tool).  These cabals may lead to behavior that may or may not be good for the organization. Turning aside the possibility of a grassroots revolute for a future essay, the isolation of the process improvement ‘elites’ from the general IT population will lead to inefficient solutions.  Involvement allows collaboration; it helps channel change making it less uncontrollable therefore making it more predictable to determine if change will generate value.   There many standard methods to try to facilitate a linkage (which different from involvement and collaboration) between groups such as programmed communication, meetings and the like. The problem is that those solutions tend to feature multiple unidirectional flows of data, people talk at each other rather than to each other.  The standard methods such presentations and deliverable reviews provide spin controlled information but not dialogs and interaction.  In the long run (measured in months not years) the gap between the elites and the general IT population will broaden as the process developers get further away from the real work of an IT organization.

One, tried and true method for making sure the wall stays as thin as possible is to staff process improvement groups primarily from other disciplines (use process improvement as a stepping stone on a career ladder).  Adding open collaboration tools such as WIKISs, RSS feeds and BLOGs intensify the interaction and create an intimacy that builds value and community. The goal is to ensure that the decisions made when designing and implementing new processes are tailored toward facilitating work and delivering value.  Involvement requires that those designing and developing processes have to ‘eat their own cooking’, in other works live by the consequences of their actions in the crucible of software development and maintenance.

The second idea I gleaned from the lecture, the inability to reassess core values is perhaps a more insidious problem.  Societies, organizations and even teams develop patterns of behavior to guide them.  In IT, we call these patterns; frameworks, methodologies and processes.  Without a periodic reassessment of how the organization’s values are supported by implemented methods and processes it is impossible to be sure that the most efficient and effective path will be followed.  If a significant shock to the environment goes unrecognized (a change in technology or globalization) efficiency might be the last thing you worry about as your process choke output. In short, processes and methods need to be reassessed periodically based on current conditions, organizational needs and values. Methods and processes should not be elevated to belief structures (e.g. the church of the CMMI or cult of the eXtreme).  What has served you in the past may not serve you in the future.

Transparency and involvement are important to delivering change that lasts but aren’t all that is needed to generate continuous value (a good start though).  The problem is that change that lasts does not necessarily equate to value. What if the change starts to impede delivering value as the environment changes?  Transparency, involvement and reassessment of software processes and methods based on current values and needs; is the prescription needed to keep the ship of IT pointed towards delivering value.

Keep the Ship of IT Pointed Towards Delivering Value is a rework of an essay from earlier in the year.  I like this version better, so much better that I recorded it for my podcast (SPaMCAST – www.spamcast.libsyn.com).  Please read or listen.  Comments and suggestions would be appreciated.

 

 

Keep the Ship of IT Pointed Towards Delivering Value

Thomas Cagley Jr.

A few weeks ago I attended a lecture by Jared Diamond.  His lecture was in support of his book. Collapse: How Societies Choose to Fail or Succeed (2005).  The ideas in the book concern the anthropology of societies however they are equally relevant to why process improvement programs succeed or fail.  Two of the ideas Dr. Diamond put forth on why societies collapse that are instantly germane to SPI programs.  Thet were:

  • Elites isolate themselves, and
  • An inability to reassess core values

The fourth definition of term isolate on Answer.com is to ‘to render free of external influence; insulate’.   Organizations that leverage the factory model of IT, create stovepipes, then assigns groups and roles (like SPI) to the stovepipe which causes isolation.  How many cube farms have you been in where a person in one group may sit next to a person in an another group yet neither know each others name unless is stuck to the outside of the cube?   I would suggest that the stovepipe / factory model of IT has supported the creation of insular specialists such as development methodologists, process improvement specialists, project managers and DBAs.  This isolation is in effect a gating / cutting off of decision making groups from those they affect especially when it comes to support groups like process improvement groups, PPQA and project management.  One management theory suggests that specialization in a production environment is more productive.   I would suggest that in scenarios where there are more knowns than unknowns this type of model can be very efficient.  The model of specialization tends to breakdown in scenarios where the unknowns outweigh the knows and a solution requires interdisciplinary knowledge and interaction.  Using a specialist model in the later scenario reduces efficiency, creates unrest and requires management to expend effort to control work rather than on motivation (a directive versus leadership model).   One of the unintended consequences of putting up barriers is the creation of fertile grounds for grass roots movements (such as teams deciding to use agile methods on their own or not to use a specific tool).  These cabals may lead to behavior that may or may not be good for the organization. Turning aside the possibility of a grassroots revolute for a future essay, the isolation of the process improvement ‘elites’ from the general IT population will lead to inefficient solutions.  Involvement allows collaboration; it helps channel change even though overall change uncontrollable but it can dampen it, making it easier for change to generate value.   There many standard methods to try to facilitate a linkage (which different from involvement and collaboration) between groups such as programmed communication, meetings and the like.  The problem is that those solutions tend to feature multiple unidirectional flows of data, people talk at each other rather than to each other.  The standard methods such presentations and deliverable reviews provide spin controlled information but not dialogs and interaction.  In the long run (measured in months not years) the gap between the elites and the general IT population will broaden as the process developers get further away from the real work of an IT organization.

 

One, tired and true method for making sure the wall stays as thin as possible is to staff process improvement groups primarily from other disciplines (use process improvement as a stepping stone on a career ladder).  Adding open collaboration tools such as WIKISs, RSS feeds and BLOGs intensify the interaction and create an intimacy that builds value and community. The goal is to ensure that the decisions made when designing and implementing new processes are tailored toward facilitating work and delivering value.  Involvement requires that those designing and developing processes have to ‘eat their own cooking’, in other works live by the consequences of their actions in the crucible of software development and maintenance.

 

The second idea I gleaned from the lecture, the inability to reassess core values is perhaps a more insidious problem.  Societies, organizations and even teams develop patterns of behavior to guide them.  In IT, we call these patterns; frameworks, methodologies and processes.  Without a periodic reassessment of how the organization’s values are supported by implemented methods and processes it is impossible to be sure that the most efficient and effective path will be followed.  If a significant shock to the environment goes unrecognized (a change in technology or globalization) efficiency might be the last thing you worry about as your process choke output.  In short, processes and methods need to be reassessed periodically based on current conditions, organizational needs and values.  Methods and processes should not be elevated to belief structures (e.g. the church of the CMMI or cult of the eXtreme).  What has served you in the past may not serve you in the future.


Transparency and involvement are important to delivering change that lasts but aren’t all that is needed to generate continuous value (a good start though).  The problem is that change that lasts does not necessarily equate to value. What if it the change starts to impede delivering value as the environment changes?  Transparency, involvement and reassessment of software processes and methods based on current values and needs; is the prescription needed to keep the ship of IT pointed towards delivering value.