November 2007

Monthly Archive

Information or Data: Which Do You Mean?

Posted by on 21 Nov 2007 | Tagged as: Acceptance Testing, Agile, Architecture, Product Owner, Scrum, XP

Recently I was having a discussion about an article that mentioned IT is about managing data.  Given the rest of this article I tend to agree with the writer (sorry I have lost the reference or else I would link to it from here) but a colleague of mine, Bill Barr, responded after reading the article quickly with the following:

I crisply remember being yelled at by a VP of Catalog Marketing many years ago. She, in complete frustration, yelled, “Don’t give me data, give me information! I need interpretation!”

My colleague Lance Kind quickly responded in his humorous and creative way:

This is along the lines of Spock explaining to Kirk in his coldly logical way,– ‘Every answer is a response, but not every response is an answer.’

Although it does have a taste of higher level wisdom which could be dismissed because it may not appear valuable to your world right away but then I started to think about it further.  As a person who tends towards the values and principles of the Agile Manifesto to direct some decision making in software development it may be very important to understand.

If we dissect what was said by the VP of Catalog Marketing Bill was quoting it may become clearer.  The first couple of questions I have are “what is data?” and “what is information?”.  Here are their definitions:

data – a collection of facts from which conclusions may be drawn

information – a message received and understood

Although data may be important as a transitory artifact it does not seem to me valuable until it becomes information based on these definitions.  This makes me think about our industry’s fetish with data management and is there a different way that we can look at it?  I do have some strong opinions about the prevalent activity of managing data and ways that I have witnessed and participated in developing that may be better.  But that will be for another blog entry or more in the future.

Value vs. Return and Potentially Shippable Product Increments

Posted by on 20 Nov 2007 | Tagged as: Agile, Architecture, Product Owner, Scrum, XP

Aman, a trustworthy and accomplished IT manager, looks at Scrum and Agile for his first time. After going over timeboxes, value-driven backlogs and potentially shippable product increments, Aman assumes that this method of developing software is not applicable to their projects. Aman sees a problem producing valuable increments of software every iteration. Some of their features are much larger than what could be developed in one iteration. He quickly nudges the Agile Coach, Priya, about this major oversight on the part of their organizational sponsor for Scrum and Agile. Priya is empathetic to Aman’s position since she has held that position before. She decides to learn a little more about Aman’s world and see if they can find a way through this issue.

One of the most often asked questions I get as a Certified Scrum Trainer and Agile Coach is around potentially shippable product increments and value of those increments to the customer. In my opinion this is a question about what is “value” and how does that relate to a “return”. In iterative and incremental methods of developing software such as Scrum and Extreme Programming (XP) there is emphasis on potentially releasable product increments at the end of each iteration. This provides some benefits such as the following:

  • Product Owner is enabled to identify early release opportunities
  • Software continues to be in a more predictable state
  • Forces system integration more frequently
  • Reduces duration of stabilization phase at time of release
  • Increases early feedback of architecture and system design issues
  • Minimizes amount of architecture by only supporting implemented features

The product accrues value as we progress from iteration to iteration adding more features into the product. How value is measured for software projects may come in various forms such as:

  • Increase market potential
  • Create valuable upgrade features for existing customers
  • Reduce total cost of ownership
  • Improve operational effectiveness
  • Enabling platform for future software endeavors

Although the product may be potentially shippable at the end of each iteration there may not be enough value accrued to ship it. Therefore we use each iteration deliverable as an increment of value towards an ultimate releasable product.
Taking Multiple Sprints to Release

A value-driven approach such as Scrum will prioritize the implementation of the highest value features first. This means that each potentially shippable product increment delivered will contain the most valuable feature elements to produce a releasable product. As the release schedule progresses the Delivery Team will increase production of valuable software as the architecture becomes stable and unknowns lessen. Since we are continually working on the next most valuable features for the release the amount of value we produce per iteration will begin to level off. The following shows the value per feature added throughout a release cycle.

Value per feature added for release

Although the software has continued to get more valuable, the value is not realized until there is a release and the end users are using the software. In an Agile environment we tend towards shorter release cycles in order to maximize return on our investment of valuable features implemented in the software.

As Priya and Aman discuss the implications of potentially shippable product increments delivered each iteration Aman gets a clearer picture of what is required in breaking down the features into consumable chunks a Delivery Team can implement inside an iteration. Priya describes the accrual of value as each iteration passes. Aman finished by describing how the customers of their product can then realize this value once it is released and they start using the software. Aman now understands that a release still contains essential elements such as the sufficient amount and correct valuable features to give the customers the best experience possible with the software.

Running All Unit Tests When Saving a File in Eclipse

Posted by on 13 Nov 2007 | Tagged as: Agile, Architecture, Java, TDD, XP

Introduction

I am a strong proponent of Test-Driven Development (TDD) which has the mantra “write test, write code, refactor”. One of the most important parts of TDD is the ability to gain immediate feedback regarding the state of the code. After using TDD in many projects I have found that there are some potential areas for optimization:

  • Decreasing the feedback loop even further
  • Automating the feedback beyond the Continuous Integration server
  • Attention to the “Psychology of Build Times” (thanks to Jeff Nielsen for this presentation)

I have found that running all unit tests when saving a file in Eclipse has increased our team effectiveness with TDD and decreased our manual integration woes over time. Even though TDD can help tremendously in minimizing technical debt, manual portions of the TDD process can be prone to errors which lead to longer feedback cycles. Thus decreasing the team’s velocity per iteration.

Prerequisites

Before getting started we must identify the parts that will be used in setting up the environment:

After you have these installed please move onto the next step.

Setup Maven 2 Integration for Eclipse

There is a great flash tutorial for setting up the plugin here and another tutorial on how to use its features here.

Once you have installed and reviewed the tutorial of features you can start importing your own Maven 2 project. In the root directory of your Maven 2 project type:

mvn eclipse:eclipse

This will generate the Eclipse project files so that this project can be imported into Eclipse. Once this command has ran successfully go to Eclipse and choose “File->Import…” from the main menu. This will open up a dialog which looks like the following:

Eclipse import dialog

Choose “General->Existing Projects into Workspace” from the tree component and click “Next >”. Browse to your project root directory and click “Finish”. After you clicked “Finish” the project will be imported into Eclipse, perform a full build of the project, and then it is ready to be worked on. If you get a problem such as “M2_REPO not defined”, or something similar, make sure that you have set your M2_REPO classpath variable in “Windows->Preferences…Java->Build Path->Classpath Variables” to the path of your Maven 2 local repository which is usually “${USER_HOME_DIR}/.m2/repository”.

Once you have the project successfully imported and building, you may add the Maven 2 project nature by right-clicking your project and selecting “Maven 2->Enable”. This will allow for easier browsing of the Maven 2 repository and adding of dependencies into your project POM.

Running Unit Tests on Every Save

We should have a successfully building project in Eclipse along with a Maven 2 External Tool builder that runs successfully, or at least as well as the command line `mvn test` for your project runs. It is time to add your builder into the “Builders” list for your project. Right-click on your project and choose “Properties”. Choose “Builders” from the left-hand pane. The project properties should look something like this now:

Eclipse project properites Builders list

Click “New…” and select “m2 build” as the external tool type to create. This will create a new configuration for a Maven 2 enabled runner to be filled in with the appropriate information. In the “Name:” field type “Project Unit Tests”. In “Base directory” click “Browse workspace” and select your project’s root. In the “Goals” field type “test” which will do all of the steps up to and including running all unit tests for your project (same as running `mvn test` from the command line). Under the “Common” tab our teams usually make the external tool builder a shared file in the project root and check “Display in Favorites menu”, as well. The configuration should look something like the following:

Eclipse external tool for unit tests

After you have completed all of that click “Apply” and then test it by clicking “Run”. Please review the steps above if you find any errors.

The Wrap Up

TDD can be effective way to reduce technical debt in your code and provide increased delivery capability for your product delivery team. An important piece of TDD is the more immediate feedback to a team member regarding broken components and functionality. Providing a mechanism in your Java project with Eclipse to automate and decrease the duration for feedback can make a team even more effective than using TDD alone.  This article focused on the use Maven 2 for building your project and for integration with Eclipse.  A similar approach could be taken for creating external tool builders for Ant or Eclipse-based unit test targets.

Please let me know if you are using these tips and how it is working out for you along with any additional information you would like to provide. Good luck.

AYE Conference – Day 3

Posted by on 08 Nov 2007 | Tagged as: Agile, Leadership, Scrum, XP

Wow! Again it was a wonderful day at the Amplify Your Effectiveness (AYE) conference in Phoenix, AZ. My only regret is that it is the last day of the conference. Here is what I gathered on the day:

Writing Workshop presented by Naomi Karten and Johanna Rothmann

I have been doing some writing lately and I this workshop was a great way to help improve my skills in writing. The first exercise that we did included gathering 4 random words from others and including those words in a 5 minute writing exercise. Here was my output from the words inspiration, care, limber, and diagram:It was an inspiration that Dwayne took tremendous care in developing such a limber diagram of Monty Python’s influence on American culture.

We then discussed some techniques and topics of interest such as:

  • Personas – identifying your audience through pictures and names for the different audiences you are writing to
  • Adjectives – use singing adjectives that truly inspire
  • Adverbs – don’t use with some exceptions identified by participants such as fiction and when it “really” works (really and very are adverbs we should stay away from)

We did a second exercise which was 15 minutes of writing on any topic we are interested in. Here is my output from this:

Why does news only constitute bad news? Are shock and awe strands soldered into our DNA? I despise what current news portrays yet I am drawn to it on occasion.

One day I sat in my care with my ears fluttering in and out of public radio broadcasting. A broadcast caught my attention. A boy in his teenage years started a charity for building wells in Africa. I was immediately baffled. How could inspirational news seduce my passion?

After dodging and judging my own life’s charitable inadequacies I stood in a parking lot embroiled in an idea. Are we desensitized enough as a society to thirst for narratives of virtue? If so, what could I do about it?

Now, here’s where my story begins…

This workshop was lots of fun and I recommend it to anybody interested in writing.

Putting your Power to Work presented by Dale Emery

It was interesting to discuss “power” with such a great group of people.  Our first exercise was to define “power” by ourselves and then get into a group of 5 people and agree to a definition between us.  Here is what the team I worked on agreed to:

power – def. Potential to manifest change

I won’t be able to discuss each word and alternatives we went through in coming to this definition but I can tell you it was quite interesting to participate.  During the team part of this exercise we were asked to list examples of power that manifested in the exercise.  The activities which were identified as indications of power were fun to talk about and understand in terms of perspective.

We discussed the beauty of abstraction in values.  Here is an example from Dale:

An executive told me about one of the core values which was “fun”.  While going around the company we asked people what the company’s core value of “fun” meant to them.  They seemed to all have a different definition of “fun” and I asked the executive if that meant it had no meaning to the company.  He replied that this was the beauty of the abstract value “fun”.  Each person owns and crafts that value into something that is important to them.

I found this profound and a great way to discuss values including those in the Agile Manifesto.

Dale brought up another topic called the “Abilene Paradox” which is a book by Jerry Harvey.  Here is the story as I remember it:

A group of people were together at a house about 50 miles out of Abilene and were starting to get quiet.  One of the group members said to the rest of the group “why don’t we go to Abilene for something to do?”.  The rest of group looked at each other and decided to do it.  It was a very hot summer day and they had to travel 50 miles in a car with poor air circulation, go into Abilene and walk around in the heat, and then make their way back to the house.  When they got back to the house one of the group members said that they didn’t really want to go into Abilene.  That started a procession of other group members concurring with them and even the person who originally asked the group.  That person had just been posing a thing to do and if the group said yes they would be alright with it but didn’t necessarily want to do it.

We got into this story because one of the groups discussed how they came to agreement.  They said that each person looked around after a question about the definition being sufficient was asked.  Each person was nodding their head “yes” and so everybody assumed that all team members agreed.  This is not necessarily the case and many people recommend that you use a consensus technique such as the “fist of five”.

Overall this conference was incredible and walk away with some “relearnings” and new tools to use in order to be more effective in my work and life.  If you are interested there is going to be another AYE conference next year and all are welcome.  It is capped to a certain amount of people allowed to register for the conference and it is first come, first served.

AYE Conference – Day 2

Posted by on 07 Nov 2007 | Tagged as: Agile, Leadership

I found myself in two more great sessions today at the Amplify Your Effectiveness (AYE) conference in Phoenix, AZ.  It just amazes me how much knowledge I have witnessed within two days here.  The following information is important information and results of my experience today.

Reflect and Adapt presented by Elisabeth Hendrickson

This session started off a bit slow because there was a limited group of attendees for an amazing simulation.  It incorporated product management, developers, testers, interoffice mail, and computers into an amazing simulation which felt like real world scenarios within software development organizations I had been part of or witnessed.  I could not believe how writing instruction sets, test cases, and confusing requirements on index cards could feel so much like real life.

Two of the participants had actually run or been through the simulation before.  One of the most incredible realizations to me and others in the room was that the product manager tried to stall the customer when they asked for a demo and he knew the product was still buggy.  This may or may not have been what this person would have done in a real life scenario but many of the considerations were those that I have heard from product managers I have worked with and coached in the past.  I was a tester and it was amazing to me that I really got into the role.  When I ran test cases against the running system and they continued to have the same or new bugs I started to think “what is the developer doing?”.  As a developer this was frightening to me and it was a natural reaction to the way we started doing our work which excluded face-to-face communication.  Elisabeth did a great job of working with the group and the entire group discussed topics which related to situations arising during the simulation.  As we reflected on our work so far we would modify our working agreement which caused interesting changes into the environment resulting in improvement over time.

Resistance as a Resource presented by Dale Emery

Dale Emery had a great laid back style as he presented resistance as a resource through activities and discussion.  This session had incredibly simple but powerful activities which helped people understand what constitutes resistance.  Dale mentioned quite early that he did not know much about resistance but has found that he does know something about fielding responses.  This statement may seem cryptic and I believe that you may have to be in one of Dale’s sessions to actually understand it.

Two things really stood out for me in this session:

  • If you are not willing to change yourself when encountering resistance then it may not be helpful to confront the resistance yourself at that time
  • When encountering resistance, if we are rigid we may become easy to knock over but if we center ourselves before confronting the resistance we can work through differences

The second item may be confusing so I will do my best to explain.  When we center ourselves we are establishing our ability to move with the resistance to find a point of view which both parties can move forward from.  One way to do this is by asking yourself “what do I want to get out of this?”.  This can help you center yourself by understanding the intent of your suggestion.  Once you are centered or congruent you can work with other people who are resistance to the changes you are proposing to them by using techniques such as reflective listening followed by curiosity about finding more information about the situation which may be helpful information on how to move forward from each other’s positions.

During an exercise where I posed a change I wanted to make in an organization another person I was amazed at the responses we found as a pair.  Upon being questioned by the other person about the feasibility of my plan I began to ask if they were not able to meet my needs.  They found it difficult to move forward with me and at one point I found myself in a position of bullying power which was uncomfortable.  We both spoke more in depth about the situation and each of us learned quite a bit from this short role playing exercise.

AYE Conference – Day 1

Posted by on 06 Nov 2007 | Tagged as: Agile, Leadership

I am currently at the  Amplify Your Effectiveness (AYE) conference in Phoenix, AZ.  Although I have only participated in one day of sessions it has been an overwhelmingly worthwhile experience.  When one gets around this many talented, passionate, and knowledgeable people there seems to be a learning experience around every corner.  I thought that I would type some notes from today’s sessions.  I am going to be careful not to discuss how the sessions were conducted since I believe it is important to be in the context of these sessions and simulations in order to fully understand any context I would attempt to convey through written word.  They are just that powerful in person.

Dynamics of Distributed Teams presented by Esther Derby

Although I work with many distributed teams in my consulting on Agile there seems to always be a bit more to learn.  The items below are quick list of ideas:

  • Imposing collaboration across team boundaries may create problems.  In the simulation, some folks from the main office, including myself, attempted to get together with an off-site team in another location after running separated for a while.  The off-site team had gotten used to a certain solidarity which made them feel quite effective in doing their work.  The main office team saw an opportunity to be inclusive of the off-site team in planning how we were going to implement the company vision.  Taking this opportunity without giving the off-site team options for using their time in this manner, enough notice to discuss and plan, and imposing our main office culture onto them was problematic.
  • Aligning on a vision which is understood across office locations helps create more collaboration on how to coordinate the work.  We were given less information about the company vision and how the product lines supported that vision at the beginning.  It became apparent at one point in time that we needed alignment when one project asked a fundamental question which had huge ramifications based on the answer.  Upon hearing the answer to that question and discussion with other groups about their understanding of other information it was clear that we had been running with different objectives in mind across the group.
  • Try to get alignment before a separate culture sets in fully is a good preventative measure.  If possible, get distributed teams together early on to create a sense of affiliation with the entire team.  Also, continually work on keeping that sense of affiliation current throughout the life of the project.
  • Getting things done is not necessarily doing the right work.  Without a coherent vision that was understood by the teams we found ourselves not fulfilling the needs of the company to keep us in business even though we were allocating ourselves as management had requested.  The teams got together with the later acquired vision and decided how we would meet the needs of the company and also our individual aspirations.
  • Be careful, even as a team member, that external suggestions of “how” to do the work of another team can create distrust and resentment.  There was a message which was passed from the off-site team to the main office which asked for more information on “what” should be built.  A message was sent back from the main office which told the team an obvious strategy for “how” to start the work.  Later on in the session we debriefed each team and they mentioned this message as a “duh” moment for them.
  • “Words can create worlds” – Diana Larsen.  Diana participated in the session and made that statement in response to the use of “home office” and how that is perceived within the context of multiple site companies.  Most of the group perceived this to mean that all decisions would be made at that location and correspondence from the “home office” was highly scrutinized.

Congruence is the Foundation for All Effectiveness presented by Jerry Weinberg and Dwayne Phillips

The context for having a conversation about congruence seem to stem from this question posed by Jerry Weinberg:

Have you ever thought “I could have handled that better”?

Congruence is described as a balance between self, other, and context which embodies self-esteem.  When we are in situations with other people we may be incongruent and therefore ineffective in handling the situation.  Here are some ways that incongruence can manifest itself:

  • Leaving yourself out; placating – def. tending or intended to pacify by acceding to demands or granting concessions
  • Leave others out; blaming – def. a reproach for some lapse or misdeed
  • Leaving self and others out; super reasonable – excessive reasoning which does not fully take into account the context and actors of a situation.  This behavior could be identified by listening for queues such as usage of “there is” or “it is” instead of “I” and “you”.  Reasoning without the context of the people involved.

One interesting note that I took was the thought that asking too many questions of our customer’s requirements could cause customer to feel blamed.  Too many questions can seem to indicate a dissatisfaction with the requirements and therefore the person or people delivering them to your team.

Another great quote for me was “90% of the message is not in the words”.

Definition of “self-esteem” and “self-confidence” was good in that it helped put these terms into context with each other.  My interpretation of the definitions demonstrated were:

Self-esteem – how one values themselves along with other people

Self-confidence – how you assess your capabilities to take an action

I took away an important lesson overall which is that helping others get congruent when we are working together involves bringing them into the “here and now”.  We all have different backgrounds and understanding of the past which could be plaguing our ability to invest in our future.  By bringing our awareness to the “hear and now” we can be open to improving our capabilities for the future.  But even after we seem to get congruent at the start of an interaction we must continue to cultivate the congruence of the interaction.  We can check into the group and see if there are changes in posture, tone, and attention which could make the interaction become incongruent.  An example may be the group starts using references to food as analogies which may present an incongruence that people are hungry and need to eat before moving forward.

I recommend anybody who would like to become more self aware and effective come to this conference.  I know that I am saying that after only one day but I can already see how much value there is in it.