Two Times

JP my good friend and local philosopher first introduced me to this idea when he told me about two different greek words for time:

Chronos refers to chronological or sequential time.

Karios refers to the time in between, a moment when something happens. The appointed time, the crucial time, God's time.

Chronos is quantitate, I am writing this at 4:23pm CST. Karios is qualitative, is now the right time? Being aware of this dimension of time is how you know that the season is about to change.

When I read Shakespeare's sonnet 18 of "eternal lines to time" the picture above began to form in my mind. 

But thy eternal summer shall not fade,

Nor lose possession of that fair thou ow'st;

Nor shall Death brag thou wander'st in his shade,

When in eternal lines to time thou grow'st:

I have since become interested in Eckhart Tolle's teachings about the Power of Now which restates this truth and also provides insight into how we can be more aware and present in the moment, in the now. One of the barriers to being fully present in the pull of the ego whose existence is based on past memories and future planning, it lives in the temporal plane and is born and will die. His later book A New Earth looks deeper into the structure of the ego and how by "being in the now" is the key to transcending the ego and living with greater presence. 

My struggle comes from not being in the moment. I spend a great deal of time in thought, imagining better futures and a fair amount of time worrying about past actions. Right now am I not fully in the present, not fully focused on creating and writing this blog - I am aware that I am going out tonight, have to get ready to bike to work in the morning and balance my checkbook. The awareness of not being in the moment is, however, a good thing, it can shine the light of consciousness (which flows from the now) onto the temporal musings of my ego!

I have experienced the now, in times of stillness, in times of celebration and dancing and in times of creative flow. The now is not static, it is a dynamic moment, where all energy flows from, all past and future events converge, all experience happens and where everyone can be one with the source.

Saying "Yes" to the present moment is a foundational concept I will returning to in future posts as I continue my struggle to be authentic. Here is a link to a great page on Wikipedia on Kariosand here is a link to learn more about Eckart Tolle.

Interactive Technical Retrospective

On Saturday I am going to Social Dev Camp Chicago. In the spirit of the rules of Bar Camp I have signed up for a slot on Saturday to facilitate an interactive technical retrospective.  I confess I wanted to talk in the Business and Culture track and share my story about my business WeaveThePeople.com, however, all the slots were taken so I signed up in the Technical Track and now that I have, I am getting quite excited about my session. Also a little nervous and feeling unprepared but I think that's okay!

My plan for the session is to map out on a time-line the most monumental technologies, tools, techniques, books (techie books), programming languages and applications for the attendees. Note to self: bring post-its and a large roll of paper.

My goal is to capture the technical influences of the group, tap into our collective wisdom, look for patterns and hopefully reveal to all of us a glimpse of what is happening right now.  I saw Gary Vaynerchuck speak at the Tech Cocktail conference and he said that if this if we are to compare the current state of social technologies to a baseball game, we are in the first verse of the national anthem. This resonates with me, I have a hunch that something very exciting is happening right now and all of us in the technical community are in a great position to be active participants in this revealing.

I am passionate about philosophy, in addition to technology and collective intelligence, and this is one of my motivations behind this session. This blog is named after an essay written by Martin Heidegger, The Question Concerning Technology. In this essay he talks about the essence of technology, this took me some time to read - I remember one afternoon on Foster Avenue beach my girlfriend giving me a hard time that I had been reading the same page for an hour! I say this because it is hard for me to summarize Heidegger's writings - so I'm not going to attempt to do it, read the book.  I will however share a quote:

“Technology is therefore no mere means. Technology is a way of revealing. If we give heed to this, then another whole realm for the essence of technology will open itself up to us. It is the realm of revealing, i.e, of truth.”

What I can also do is share with you my own philosophy influenced by Heidegger. I believe that we can choose to be active participants in the unfolding of the world as we know it. By paying attention to what is happening, specifically in the world of technology, we can learn to read the wave (this is what I hope to glimpse as part of this session). We can then partake in this revealing by surfing this wave. We do this by creating new stuff. We do this by not just doing but also by being, being aligned with what is ready to be revealed. Our surfboard can be as simple as a question we don't know the answer to, this will lead us into the unknown. Why do we do this?  To have fun, to tap into our passion and live more fully.

A reminder, I write code not philosophy! So I'll leave you with another quote from Heidegger:

“Where and how does this revealing happen if it is no mere handiwork of man? We need not look far. We need only apprehend in an unbiased way....Whenever a man opens his eyes and ears, unlocks his heart, and gives himself over to meditating and striving, shaping and working, entreating and thanking, he finds himself everywhere already brought into the unconcealed.”

What is an Effective Requirement?

Chris from Telelogic presented a Webinar on Writing Effective Requirements yesterday. I noticed around 500 attendees, looks like there are several of us asking: “What is an effective requirement?”

In my role as a solution architect I have to ensure that the technical teams and the business teams share a vision of what is being built. From my entrepreneurial experience I recognize the value of a compelling vision, a focused mission and measureable success objectives. Assuming all these are in place we then begin to gather more specific requirements.

The picture here shows that is well worth the time to create quality requirements early in a waterfall project phase. Agile does reduce some the risks of unclear requirements by providing feedback earlier, however, the guidelines Chris shared for what makes a good requirement, apply to both creating a requirement document in waterfall process and a user story in an agile process.

Let’s look at an example of a good user requirement:

The internet user shall be able to access their current account balance in less than 5 seconds.

Here we define a user type: the internet user. The “to be verb” is prefixed with “shall” which has a consistent meaning of mandatory (along with "will" or "must"), “should” means optional, “may” is desirable. The positive end result is “access to their current account balance”. Measurable success criteria is “5 seconds”

This example meets these structural elements of a requirement:

• Complete Sentence
• States subject and predicate
  - Subject is a user type
  - Predicate is a condition, action or intended result
• Consistent use of Language
• Specifies
  - Desired goal or result (User requirement)
  - Function (System requirement)
  - Constraint (either)
• Contains a success criterion or other measurable indication of the quality
  

In addition to following structure, Chris shared these characteristics of a good requirement:

• Correct - Technically and legally possible
• Complete - Expresses a whole idea or statement
• Clear - Unambiguous and not confusing
• Consistent - Not in conflict with other requirements
• Verifiable - It can be determined that the system meets the requirement
• Traceable - Uniquely identified and can be tracked
• Feasible - Can be accomplished within cost and schedule
• Modular - Can be changed without excessive impact
• Design-Free - Does not pose a specific solution on design
• Positive - Written in the affirmative, not the negative

The challenge is seek out the user type, end result and success measure in EVERY requirement defined. This is one of the challenges I face working in a waterfall process is to hold the team accountable to follow these guidelines without slowing down an already very time consuming phase. I confess, I am often eager to get into the design and code phase and I let these things slip. One of the reasons I am choosing to write this post is to present guidelines at the beginning of the phase. I hoping Eric who is stepping up to fill a business analyst role will find these useful – let me know!

I asked Chris at the end of the presentation what is the difference between a requirement and a user story. He replied that they are basically the same and that these guidelines apply to both. The guidelines are useful, I agree, specifically on how to write a requirement, a user story, however is not the same. A user story in an agile process emphasizes the role of conversation and testing, in addition to the written requirement.

As Mike Cohen reminds of this and highlights further differences in a great article, Advantages of User Stories for Requirements:

User stories are not just these small snippets of text. Each
user story is composed of three aspects:

1. Written description of the story, used for planning and as a reminder
2. Conversations about the story that serve to flesh out the details of the story
3. Tests that convey and document details that can be used to determine when a story is complete

I see several other major differences with what we do with these requirements in agile approach vs a waterfall process.

• Agile prioritizes all requirements; waterfall typically groups them by functionally
• Agile only elaborates requirements when they are about to be implemented; Waterfall completes requirement details in the requirements gathering phase
• Agile welcomes new and changing requirements; waterfall discourages changes using change control processes.

In conclusion, I think there are some useful guidelines here for writing effective requirements that can help our teams within our current waterfall process and I think the competency will continue to be valuable in writing user stories in an agile process.

Want more? Check out these other interesting links I found:

We don't need no Stinking Requirments, reminding us agile processes still need requirments (also nice link at the end on writing requirments)

The 1997 article by Steve McConnell with a narative around the picture above.

Wikipedia links: User Stories and Requirements

Two Loves

This was originally posted on my struggles concerning authenticity blog. This is concept I continue to struggle to understand, I like the image and I never got around to adding the words! I will return to this post and write a more thoughtful post, however, here is something so we can, at least, begin a conversation.

The best explanation of these two types of love I have come across are in the story Tristan and Iseult , the best translation and explanation for me was in the book We by Robert Johnson. (I can lend you my copy).

In this story, Tristen, falls in love with Iseult, she represents Perfect Love in this image or Spiritual Love. It is a mistake to try and find this kind of love in another person. Jung talks about this when he refers to a man's desire for the Anima, Animus for a woman. This is an inner journey to become whole. When we try and project our desire for the Anima on to a real woman it ends in disappointment and often tragedy as in the story.

The other woman, Iseult of the White Hands represents Relative Love or Erotic Love. This is the mortal human kind of love, with the associated erotic activities! This love is not perfect, not eternal and is part of the rhythm of life including the ups and downs. The terms Relative Love and Perfect Love come from the book Perfect Love, Imperfect Relationships: Healing the wound of the Heart. Great book, this is what prompted the post. Tina and I are reading it together. One immediate benefit we have both found is to allow for the natural ups and downs in our human love and not expect the unwavering, eternal, perfect love from each other. This perfect love comes only from within, from the source, from being one with all life.

Another story that touches on this is one is in a kids book I have for Zach, The Legend of the White Buffalo Woman, again she represents the spiritual woman. In this story one of the tribesman touches her and gets vaporized - tragic!

Our current romantic culture still presents the idea that this spiritual fulfillment can be achieved by finding the right erotic partner.  When that feeling of un-fulfillment continues, divorce and a search for another partner. Can we experience these two loves? I believe a key is to know they are different.

Agile Lessons from Google

Martin sent me this link to an excellent video of a retrospective on Google's Scrum implementation by Jeff Sutherland. I found it well worth an hour of my time to watch. It addressed several questions concerning agile technology that I have been asked:

Eryn asked me a few weeks ago: "Who is using agile?" Google for one! Other companies that were referenced in this presentation included: Nokia; Ford; Microsoft; Yahoo; BellSouth and Toyota. When asked if this scaled down, Jeff also mentioned he had worked with several start-ups and three people are enough to form a team and benefit from Scrum. By the way Eryn, I spoke to some of the vendors at Better Software and discovered that Kelley Blue Book and Edmunds are using agile (some partners and competitors of us here at Cars.com). Some other companies that I know you are familiar with include Salesforce.com and Endeca.

I have been asking myself, “How can I convince the executive management team to change to agile?” A great line from the video (minute 35) that I think will speak to the executives is how Toyota achieved 4-times the productivity and 12-times the quality than their competitors by shortening the cycle time. To go faster you have to run at higher quality. By shortening the cycle time, you force things to work. In agile software development, the lesson here was to bring QA into the iteration – touching on another question I am being asked about how QA fits with agile.

“When is agile not needed?” This is a question I have heard from multiple people and there is an assumption tied to this question that our waterfall approach is still useful for some of our projects. Well Jeff talks to this one (minute 49:30), he responds by asking another question, “Is there any reason for the organization to change?” and if the answer is “no” he will say agile is not needed. If this is the case and he senses that there is no motivation for change and says “as long as you have no competition you will be fine, call me when you have a need.” This reminded me of the two questions that Kent Beck asked potential clients “Do you have a problem?” and “Do you want to fix it?”, if either of the answers was no, he walks away. I am asking the change question here at Cars.com and a far larger percentage of people are seeing a need for change, than when I asked a year ago. The other point that resonates with me is that introducing agile approaches leads to organizational change, it is not just another software process that can co-exist with waterfall in an unchanging organization.

Kate asked last week: "Can I publish an interview with someone who has succeeded in introducing agile techniques to an organization?" I was going to share some notes from a great conversation I had with Matt from Endeca who in summary introduced agile to Endeca initially to a team of 50 developers, then to the organization and 2 year later no-one wants to go back. I think this interview is even more insightful, partly because you can watch it yourself! Here are some of the points from the video that resonated with me about how organizations transform to agile successfully.

Mark at Google started by asking the developers what their number one problem was, the answer: "Missing our dates." In response to addressing this problem (minute 22 on the video), and this problem only, burndown charts (this is the picture above) that some agile teams were using was introduced. The key point here is that the biggest problem was addressed, if something simple and easy is used to introduce agile you will not get the benefits. Mark knew this would not fix all the problems but would surface other problems, which it did and this naturally led to other agile practices being introduced when needed.

At Yahoo a single engineer went to Scrum training, started using some agile techniques on the Avatar project he was working on, the word spread which led to a 45 minute pitch to the whole management team and Yahoo went agile. The message here is that it can be a ground up initiative, the practices have a viral quality and unless it is squashed by management it can transform whole organizations, which is actually required before the true benefits can be realized.

A Leader's Model for Change

I am having several conversations at Cars.com about changing our IT processes from waterfall to agile. Bill, one of the senior leaders, asked me how he and the executive team provide direction in a more collaborative agile culture. One of the keys to how the leaders provide direction is in a shift of attention from actions and structure to identity and tone, the inner two aspects of the flame model.

Several companies have spent large sums of money bringing in consulting companies to address process improvements, only to discover after years have past and millions of dollars spent, the same problems exist. An explanation for this is provided by considering the flame model. This model is used in Dialogos' Leadership for Collective Intelligence program and is a varient of their Dynamics For System Intervention model.

ACTIONS: The top level of the flame is the most visible, what are people doing and clearly an essential focus in leading a successful organization. Easy to measure, easy to identify problems, easy to add a Next Actions agenda item at the end of meetings.

STRUCTRE: For sustainable change, the typical next place to focus is to improve the structure, the procedures, and the process. Working in IT, I have seen many process changes and am currently proposing we change to an agile process. I know that without changing the tone and identity of the IT department we will not succeed in bringing about sustainable change.

TONE: This is quality of the energy in an organization, the atmosphere, the mood. One way I feel it today is in the reactive fire fighting modes IT operates in – this actually fuels action but not in a sustainable way as it is often followed by burn out. Cars.com introduced a new branding message for our super bowl commercial “Confidence Comes Standard” – this is a tonal message. I would love to change the tone of IT to one of relaxed confidence.

IDENTITY: This is the core of the flame. When leaders of organizations focus on the core vision, mission and how they identify themselves, they can then set the desired tone, through authentic communications and actions. From this place creating structures and associated actions flow easily. All the successful entrepreneurial companies I meet in Chicago have a very well defined identity; examples that spring to mind are Threadless and Feedburner.

The agile approach does include some tonal considerations; specifically there is an atmosphere of collaboration and respect between IT development teams and the business product owner teams. For a change to an agile approach to be successful at Cars.com however we will need the support of our executive leaders to change how the company identifies IT and this may even change the identity of the company.

For leaders to use this model in introducing change, it is helpful to go down the flame in diagnosing the current problems, then up the flame to introduce the desired furture state.

Two Worlds

Mandorla is the name of this symbol of the two intersecting circles. The word Mandorla means "almond" the shape in the middle, which I have colored green. It is the intersection of two worlds:

• material and spiritual
• time and timeless
• conscious and unconscious
• divine and human
• it holds the tension of opposites.
  

The symbol has its roots in medieval Christianity, the Christian fish incorporates it.  

I love the simplicity of the symbol, I've added the colors and will be using these in some other models as I strive to increase awareness of who I am. I first came across this symbol in Robert Johnson's Owning your Own Shadow, who convinced me that this is a powerful symbol for our torn world.

I get meaning of this symbol in my head, can witness in others and to be honest not sure what it actually means in my own life and may be that is okay if symbols are beyond our understanding.  I do know I am struggling to be successful in the material world and also struggling to maintain a connection with my spiritual energy even though I feel it in moments of awareness.  I'll let you know if it helps and wanted to share it with you.

Here it is on the Chalice well in Glastonbury in England.