Guild Blogs

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Individuals volunteer to refactor for the team

Forces:
Trying to take responsibility on behalf of the team
Some people do not refactor enough
Some people are afraid to refactor
Because they don’t know how to do it
Because they don’t want to change someone else’s code
It is faster for the one who knows how to refactor to just do it than teach the others
Only one person knows how to refactor or has good OO skills
Schedule pressure does not allow the team to practice/learn refactoring
“if it ain’t broke” attitude.

Consequences:
Top producer no longer produces (busy refactoring)
Never enough refactoring, never improves
Generates refactoring stories which have no acceptance criteria and no direct business value
Hides the real problem – “failing late”
People never learn the real value of refactoring

Example:
XP enthusiast introduces XP to a new team
Team starts to practice TDD, but doesn’t refactor enough
Team learns to refactor slowly
Leader feels pressure to produce and “leaves” simple design to go faster

Better solution:
Plan for the learning curve
Refuse to refactor along
Remember to refactor only to implement a story
Don’t accept story submissions with obvious design smells
Review more until refactoring improves.

Exceptions:
Team made up of contractors
Short product lifecycle (maybe)
Single use utility

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor Solution:
Concurrent work on to many stories
None of the stories are done at the end of the iteration.
All stories are in progress.

Forces:
Desire to go as fast as possible
Big stories are not split (seem to be unsplitable)
Belief that multitasking is faster

Consequences:
Stories don’t get finished
No data to plan the next iteration
The team feels bad
The team gets blamed
There is nothing to integrate

Better solution:
Split stories so they can be completed
Take on fewer stories per iteration
Minimize work in progress

Exceptions:
None

Here is the description of the workshop I ran at XP2006:

Agile methodologies are just as prone to mistakes, deviations and subversion as any other methodology. This workshop is intended to discover and share agile process anti-patterns then discuss and present creative solutions.

Anti-patterns, also referred to as pitfalls, are classes of commonly-reinvented bad solutions to problems. They are studied, as a category, in order that they may be avoided in the future, and that instances of them may be recognized when investigating non-working systems.

This workshop focuses on participants’ (less than perfect) experiences in the workplace and mines the collective wisdom of the group to come up with creative solutions via a fishbowl process followed by breakout sessions and then group presentations. This is a half day workshop.
A fishbowl is structured conversation technique where a small number of people sit in front of the group (in the fishbowl) and converse with each other. The audience listens and at any time a member of the audience may become a member of the fishbowl, replacing one of the existing members.

I promised that I would post the results of the workshop and I (finally) have them prepared.

Workshop Antipattern List

Session 1

• Coach as manager
• Scrum master is nominated
• Worst employee as scrum master
• Too many stakeholders
• No iteration planning
• Story not really done
• Splitting stories for credit
• Velocity as dial
• Iterate without delivery
• Iterations as checkpoints
• Micro-stories
• Stories to big
• Not enough stories
• Too many meetings
• Unit tests as specification
• Specialist handoff
• Steering because you can
• Refactoring butler/gnome
• Refactoring task/backlog/iteration
• Breaking someone else’s tests
• Rebranding departments as scrum teams
• Desert island teams
• Manager is the product owner/customer
• Tools getting in the way
• Technologist as customer
• Come back when you are done
• Customer proxy believes he is the real customer
• When pairs don’t swap
• Too nice a guy in charge of planning

Session 2

• 0 Velocity Iteration
• Testing after release
• Stabilization iteration
• 80% complete stories
• Customer won’t choose
• Only new stories get worked
• Feedback ignored
• No sprint demos
• Lack of effective acceptance testing

For more info see:
http://pdx.techevents.info/codecamp/2/default.aspx

The schedule is here:
http://pdx.techevents.info/codecamp/2/agenda.aspx

The 7th International Conference on eXtreme Programming and Agile Processes in Software Engineering
June 17 - 22, 2006, Oulu, Finland

Agile software development methods and solutions have drawn a lot of attention in the software industry in recent years. The rapidly growing scientific and practical evidence show many quality gains including increased productivity, better quality and increased customer satisfaction. Agile innovations are currently moving into new domains, such as the embedded development industry, safety-critical products and other complex development environments. Movement towards business agility is also emerging in the field.

The XP 2006 conference offers a unique forum for industry and academic professionals to discuss their needs and ideas for incorporating agile methodologies into the production models. XP 2006 facilitates the exchange of ideas in a number of ways, including high-profile keynote speakers and professionals on the cutting edge of the Agile Processes, technical presentations, special activity sessions, panels, posters, code camps, workshops, tutorials, and other opportunities to exchange and elaborate the new findings. XP 2006 also features a PhD Symposium for PhD students.

http://www.xp2006.org for more information.

The following is an excellent resource on Dependency Injection and Dynamic Service Locators in .NET:

http://weblogs.asp.net/cazzu/archive/2004/05/10/129140.aspx

My prediction is that Windows Communication Foundation will turn out to be a huge sucess for Microsoft, and we plan to utilize it on Ellis (project name).

Much has been written about the latest buzzword to emanate out of the cubicles of IT shops and, surprise surprise, it's another acronym. SOA stands for Service-Oriented Architecture, and has been around for many years. In recent months it has taken off, with vendors, professional service firms, webzines, and my plumber Jim all providing their own definition and explanation, pro and con. In the vendor space, IBM is now packaging 13 (not a typo) websphere and Tivoli products around SOA. However, finding a common understanding, let along simple definition of SOA is not easy.

So what is all the buzz about? Wickepedia defines SOA as such:

In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, nodes on a network[1] make resources available to other participants in the network as independent services that the participants access in a standardized way. Most definitions of SOA identify the use of Web services (i.e., using SOAP or REST) in its implementation. However, one can implement SOA using any service-based technology.

And the definition goes on and on like this, smelling very much like the latest brew to come pouring out of the IT department down in the bowels of the company's basement.

As the technical architect on a project that is on the SOA path, considerable effort has been spent trying to determine what SOA truly means to a project, and to the company's strategy and growth plans.

As my current project evolves I plan to keep an active journal detailing what goes right, and not so right related to SOA. For this first post, here's a quick summary of what SOA means to me, and how it most relates to the success or failure of the engagement:

SOA is not so much an architectural framework, or a set of architectural best practices, or a specific vendor solution, as it is a guiding principal or philosophy around the purpose a software project or packaged vendor solution lives for. Those people controlling the purse strings in an organization are very concerned about the real ROI a project is forcasted to bring back. What SOA brings to the table, more than anything else, is the opportunity for greatly expanded returns the investment in the project required. This is accomplished through the extensibility and ubiquity. An example might help to best describe this.

If I did everything correct as the software architect on a project to custom build a solution.. everything "by the book", and created course-grained, stateless interfaces that abstracted the complexity away from the consumer, and incorporated other best practices into its design.. BUT, I used a .NET remoting solution as the transport protocol because it offers higher performing working software, the central tenet of SOA has just been violated.

That is, my solution may be solid in every way, except I just forced my new partner, or the latest company merger to move away from their Sun/Java shop.. and the huge costs associated with it, and instead, to spend lots of money and resources purchasing Windows, and .NET, because the "perfect solution" you created requires .NET on both the client and server. The reach of the service interfaces created, and extending them to my business partner just got more expensive.

Forcing the consumers of your services into one particular vendor's technology in order to be used might be a perfectly valid solution.. perhaps the best solution, but it's not SOA.

By utilizing XML, web services, SOAP, and other vendor-neutral technologies, your services just became available to a far larger pool of consumers. By creating a framework that is consumable by whomever.. or whatever platform is the preferred flavor of your organization, an investment in a long term growth strategy can be more easily realized.

I've heard Christopher Avery speak once and had a couple of email conversations and I have deep respect for the message he is trying to get across.

His e-Tip from Feb '06 is this:

Three ways you and I reduce our ability to respond and lead everyday:

• Denial. We close our eyes, cover our ears, and hum a comforting tune.
• LayBlame. We take the position that our problem is really 'them'.
• Justify. We say that it is 'just' the way it is.

Which of these 3 things have you seen in your organization today? Maybe all 3?

His suggestion:

• Commit to and trust your ability to respond.
• Stand in the fire and look to see what's true.
• Own it–what to do will become clear to you.

I had never read "The Deadline" by DeMarco, but it turned up on my boss' desk one day and I borrowed it.
I thought it was an enjoyable read and only violently disagreed with his attempt to say that if we would just do more up-front design everything would be better (High-performance projects spend proportionately far more of their time in design).

Four Essentials of Good Management: (p.28)
Safety and Change (p.35)
Negative Reinforcement (p.46)
The Manager’s Essential Body Parts (p.59)
Battle Command As a Metaphor for Management (p.69)
Interviews and Hiring (p.69)
Productivity Improvement (p.83)
Risk Management (p.83)
Playing Defense (p.93-94)
Modeling and Simulation of the Development Process (p.115)
Pathological Politics (p.131-132)
Metrics (p.149-150)
Process and Process Improvement (p.161-162)
Changing the Way Work Gets Done (p.179-180)
The Effects of Pressure (p.199)
The Angry Manager (p. 209-210)
Ambigous Specification (p. 216)
Conflict (p. 225)
Roll of the Catalyst (p. 238)
Human Error (p.246)
Staff Level (p. 260)
Project Sociology (p. 275)
Pathological Politics (Again) (p. 288)
Lean and Mean (p. 299)
Radical Common Sense (p. 302)

Tom DeMarco, The Deadline (New York: Dorset House Publishing, 1997), http://www.dorsethouse.com/books/dl.html. Copyright (c) 1997 by Tom DeMarco. All rights reserved.