Fall Scrum Gathering, London 2007 Reflections



Recently completing a trip to London for the 2007 Fall Scrum Gathering, it is yet again made plain to me that given the sheer size of the globe and large numbers of software engineers/practitioners available within - it doesn't matter if you believe you're good at what you do, dress well, have a nice website or work for a major international company with a reputation that gets you in the door ... either you're individually perceived as effective by the customer or you're not - and this determines how long you stay.

I met wonderful people who had many excellent problems to solve such as managing scope through a single repository (or not); understanding how to manage people in the company who have opinions, but aren't solution providers; discerning how to implement Scrum concepts throughout the company rather than simply in development alone; ascertaining what metrics and if metrics are in fact helpful or hurtful; wondering if off- and on-shore teams are complex, practical or achievable...and so on.

One interesting conversation was composed of a collection of questions regarding how to ensure sprint planning meetings had what they needed in order to plan and execute sprints. To this, we talked about the value of having all requirements located in the same place or repository; thereafter having the corporation or appropriate stakeholders prioritize said repository on a very frequent (weekly) basis; and how it only makes sense to take the top 5 or 10 requirements off the top of the list and turn them into executable statements by using User Stories: {Descriptions, Acceptance Criteria, Relative Sizes, and eventually Tasks with 'ideal day' hours associatively}. When technologists show up for a sprint planning meeting, those things they are equipped to assess, task out, and accept into the sprint are wholly dependent upon whether the user story statement, descriptor and acceptance criteria already exist. Otherwise, expecting technologists to take single statements and turn them into software systems is simply ludicrous. So, either the top 5 or 10 things on the prioritized list have been decomposed into user stories, or they haven't. If yes, they can be reviewed, decomposed, and most likely accepted; if no, skip it and move on until the next sprint planning meeting.


Another interesting conversation regarded how to take customer requirements and break them down into parts and pieces effectively. To this we discussed how to teach others to think in User Story statements, how to capture them, what they looked like, and how one knows when it has been delivered. Overall, the value of helping the customer 'fit in' to the process of delivering software requires us to work in language the customer uses naturally, everyday. For example: "As a regular user of an ATM or Cash Point, I want to Deposit money." Ordinary people speak like this, and defining 'done' can be had by using ordinary language as well in the form of Acceptance Criteria. For example: "The system should take my deposited monies from me"; "The balance should reflect my deposit"; and "I should have an option to print" are three examples of 'done definitions'. The key to capturing customer requirements frequently and often is to use the language of the user, not force them into our language as technologists or solution providers. Very specifically, when a developer can see what functional use must exist, and everyone can discern how it should be tested .. we're on the right path of definition and implementation. This is a good place to perform further research by looking at Mike Cohn's books on user stories and estimation.


And yet another interesting conversation regarded how to insure requirements were in fact something that could be fulfilled by the company when contract expectations were being crafted during the sales process. To this we discussed the need for development to equip sales with enough knowledge to craft more intelligent contracts. Perhaps include an active technologist or two in the sales process for crafting right expectations and right contract language. Consider giving Sales 'canned' activity/estimate bundles so that they know when offering up 'X', they know where the cost floor is and whether they are cutting into margin or creating actual losses. Sales only knows what they are taught; and since Development groups are often required to fulfill contracts crafted by sales, it makes sense that Development should equip Sales to make more intelligent finds.


One of the side statements we discussed is ... if Sales is only measured on revenue acquired, but not measured on integrity or sanctity of sound financial contracts with guaranteed profit margins after calculating cost of acquisition, cost of ownership, return on investment and putting it in context of total cost of ownership, no process, behavior or person can fix this afterwards. In other words, if the company specifically teaches the sales group to 'get money no matter what', then the company is fostering bad behaviors, sometimes looked upon as 'wolf pack' behaviors, that other processes will not and cannot fix in arrears. A bad contract is a bad contract and cannot alone be measured by the cost of getting it (acquisition/installation/implementation) and cost of owning it (through maintenance and licensing alone). Either the behavior has to become more fiscally responsible by looking at total cost of ownership PRIOR TO contract signing, or making profits will be hit or miss going forward with no predictability.

Regardless of what country from which we originate, we all struggle with multiple variations of the same problems. Whether bad contracts, poor requirements or more than one repository, and knowing when 'done' is 'done'. Furthermore, the most common challenge we all share is being effective from the perspective of the customer...either the customer is smiling, or the customer is wishing they had another option.

In every conversation I heard or participated in ... there was agreement by word and action in every case ... delivering solutions for customers is not a technical problem, but rather one of relationships and general sociology. We should never mistake the fact that we received our paycheck or paid invoice this week as validation that we are valuable - it just means we're still there. However, when we hear the customer say 'Thank you', compliment the effort, and most importantly - smile - we've been endorsed for just one more day. Tomorrow, we must start over and seek to add value that brings a smile to the face of our customer again.




No comments:

Post a Comment