Recent Agile Articles

Agile Goal Setting
What does it really mean to set goals in agile? Get Jurgen Appelo’s take on the importance of shared team goals and how to avoid stakeholders asserting their individual goals over the team’s. He also provides a checklist and examples to help you determine if your goals are worthy of being goals.

Read Jurgen Appelo’s InfoQ article. Colm Mulvey - Agile Chronicles November 2010 Newsletter
http://www.infoq.com/articles/agile-goal-setting-appelo?mkt_tok=3RkMMJWWfF9wsRonuaXAZKXonjHpfsX56usrW6%2Bg38431UFwdcjKPmjr1YcFScB0dvycMRAVFZl5nRpdCPOcc45P9PA%3D


And Now You're Just a Project Manager
Looking for a new gig on an agile team? Heed David Bland’s warning and steer clear of jobs with Project Manager/ScrumMaster in the title (beware the “slash” in the job title) and descriptions that list knowledge of traditional project management required, CSM preferred and PMP nice to have.

Read David Bland’s DZone article.
http://agile.dzone.com/news/and-now-you-are-just-project?mkt_tok=3RkMMJWWfF9wsRonuaXAZKXonjHpfsX56usrW6%2Bg38431UFwdcjKPmjr1YcFScB0dvycMRAVFZl5nRpdCPOcc45P9PA%3D


Changing Agile Roles - The Managers
Do you really need managers on self-managing agile teams? Steve Ropa thinks so but then again he’s a manager. Learn more about the types of managers on an agile team and the changes traditional managers need to be aware of to be successful.

Read Steve Ropa’s blog post.
http://blog.versionone.com/blog/agile-musings/0/0/changing-agile-roles-the-managers?mkt_tok=3RkMMJWWfF9wsRonuaXAZKXonjHpfsX56usrW6%2Bg38431UFwdcjKPmjr1YcFScB0dvycMRAVFZl5nRpdCPOcc45P9PA%3D


Technical Debt a Perspective for Managers
Technical debt doesn’t just appear overnight. It’s accumulated over time. Mark Levison gives his advice on how to identify technical debt, where it comes from and what to do about it.

Read Mark Levison's InfoQ article.
http://www.infoq.com/articles/technical-debt-levison?mkt_tok=3RkMMJWWfF9wsRonuaXAZKXonjHpfsX56usrW6%2Bg38431UFwdcjKPmjr1YcFScB0dvycMRAVFZl5nRpdCPOcc45P9PA%3D


Creating a Mess by "Eliminating Waste"
Lean is more than just about reducing overburden, eliminating unevenness in workloads and eliminating waste so more work can be pushed on the team. According to Esther Derby, it’s often more important for managers to pay attention to how work flows through the team rather than how fast tasks are completed.
Read Esther Derby’s blog post.
http://www.estherderby.com/2010/11/creating-a-mess-by-eliminating-waste.html?mkt_tok=3RkMMJWWfF9wsRonuaXAZKXonjHpfsX56usrW6%2Bg38431UFwdcjKPmjr1YcFScB0dvycMRAVFZl5nRpdCPOcc45P9PA%3D

Taco Bell Programming

Taco Bell Programming

by Ted Dziuba Thursday October 21 2010

Every item on the menu at Taco Bell is just a different configuration of roughly eight ingredients. With this simple periodic table of meat and produce, the company pulled down $1.9 billion last year.

The more I write code and design systems, the more I understand that many times, you can achieve the desired functionality simply with clever reconfigurations of the basic Unix tool set. After all, functionality is an asset, but code is a liability. This is the opposite of a trend of nonsense called DevOps, where system administrators start writing unit tests and other things to help the developers warm up to them - Taco Bell Programming is about developers knowing enough about Ops (and Unix in general) so that they don't overthink things, and arrive at simple, scalable solutions.

Here's a concrete example: suppose you have millions of web pages that you want to download and save to disk for later processing. How do you do it? The cool-kids answer is to write a distributed crawler in Clojure and run it on EC2, handing out jobs with a message queue like SQS or ZeroMQ.

The Taco Bell answer? xargs and wget. In the rare case that you saturate the network connection, add some split and rsync. A "distributed crawler" is really only like 10 lines of shell script.

Moving on, once you have these millions of pages (or even tens of millions), how do you process them? Surely, Hadoop MapReduce is necessary, after all, that's what Google uses to parse the web, right?

Pfft, f**k that noise:

find crawl_dir/ -type f -print0 | xargs -n1 -0 -P32 ./process

32 concurrent parallel parsing processes and zero bullshit to manage. Requirement satisfied.

Every time you write code or introduce third-party services, you are introducing the possibility of failure into your system. I have far more faith in xargs than I do in Hadoop. Hell, I trust xargs more than I trust myself to write a simple multithreaded processor. I trust syslog to handle asynchronous message recording far more than I trust a message queue service.

Taco Bell programming is one of the steps on the path to Unix Zen. This is a path that I am personally just beginning, but it's already starting to pay dividends. To really get into it, you need to throw away a lot of your ideas about how systems are designed: I made most of a SOAP server using static files and Apache's mod_rewrite. I could have done the whole thing Taco Bell style if I had only manned up and broken out sed, but I pussied out and wrote some Python.

If you don't want to think of it from a Zen perspective, be capitalist: you are writing software to put food on the table. You can minimize risk by using the well-proven tool set, or you can step into the land of the unknown. It may not get you invited to speak at conferences, but it will get the job done, and help keep your pager from going off at night.

Technical Debt

http://www.linkedin.com/news?viewArticle=&articleID=223249842&gid=90548&type=member&item=32525387&articleURL=http%3A%2F%2Fwww%2Einfoworld%2Ecom%2Fd%2Fdeveloper-world%2Fgartner-technical-debt-will-reach-1-trillion-in-five-years-415&urlhash=7Gx5&goback=%2Egde_90548_member_32525387
OCTOBER 11, 2010

Gartner: 'Technical debt' will reach $1 trillion in five years

In a new push to measure software's true cost, the National Science Foundation and Gartner are drawing attention to the problem of 'IT debt'

Computerworld

The idea that software acquires a "technical debt" that is paid in real dollars is getting new attention and research.

The National Science Foundation approved a $465,000 research grant last year on technical debt, and Gartner has just released its study on this subject, which it calls "IT debt."

Gartner puts the IT debt bill at $500 billion worldwide and says it will double in five years to $1 trillion.

A company that makes software quality tools, Cast, just released a study gleaned from customer software evaluations that puts the technical debt at $2.82 per line of code. It says for the average-sized application of 374,000 lines of code this amounts to just over $1 million in technical debt.

Frank Scavo, president of Computer Economics and management consultant at Strativa, zeroed in on Gartner's estimate, calling it bogus in a blog post, and outlined ways to rationalize an application portfolio.

But the idea that applications acquire a technical debt may have support in the development community.

Among the people who incorporate the idea of technical debt in their development is Gene Baker, the chief architect for the widely used WyStar 401K record keeping platform.

Every time a new piece of software is added to the code base, Baker said, an addition is made to its technical debt. Code is the principal and software maintenance is the interest payment, "so the more code we have out there the bigger our debt, hence the more maintenance, hence the more interest payments."

Gartner defines IT debt as what it would cost to bring an organization to a fully supported environment.

"You can run on unsupported software for a while -- lots of people do this," said Andy Kyte, a Gartner analyst, but if more and more of your portfolio is out of date, as well the components, application servers, databases, compilers, operating systems, "then your portfolio is gradually degrading over time," he said.

This degradation in IT environments accelerated with the recession, and Kyte said IT managers need to determine how much of environment is an "unsupported state or creating a systemic risk" and then let the business know about the problem.

Cast software tools are used to examine the technical quality of an application, developed in-house or externally. Jay Sappidi, director of Cast Research Labs, said part of the idea is to catch problems, such as with security or performance, earlier in the development cycle when they cost less to address.

Sappidi said its research was based on a study of customer code. Users can push maintenance issues aside, but "you cannot get rid of technical debt."

Baker said one method for controlling technical debt is through code reuse.

"The more we can reuse code, then less code there is and then when we have to do testing the less we have to test, and ultimately the less we have to maintain," said Baker, who also uses Cast tools.

The term technical debt may have been coined by Ward Cunningham, a developer, who in a 1992 wrote, in part, "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite."

Carolyn Seaman, an associate professor of information systems at University of Maryland, Baltimore County and the principal investigator in the NSF-funded project, said they are working on ways to represent technical debt, quantify it, measure it and help make it part of the decision making.

"We have an increasing inventory of old systems that are too big to replace," Seaman said.

Also see Mark Levison's InfoQ article.

http://www.infoq.com/articles/technical-debt-levison?mkt_tok=3RkMMJWWfF9wsRonuaXAZKXonjHpfsX56usrW6%2Bg38431UFwdcjKPmjr1YcFScB0dvycMRAVFZl5nRpdCPOcc45P9PA%3D

Procedures V Bureaucracy

Source BNET:

Bureaucratic organizations are inefficient, expensive, and sluggish. Most government agencies are a testament to that. Nevertheless, organizations need effective processes and procedures to grow.

Finding the right balance and knowing when it’s time for a change are two of the biggest challenges every successful entrepreneur and business leader faces.

For example, when companies are small, decisions can be made on-the-fly with minimal concern. A couple of guys chat in the hallway and, voila, a new product feature is born. And that’s a good thing. The more flexible and nimble a startup is, the better its chance of making it.

But as companies grow, negative repercussions of ad-hoc decision-making begin to appear. For example, growing companies are often plagued by miscommunication, frequent changes in direction (strategy du jour), or the reverse, analysis paralysis. Decision-making is just an example of a broad range of ad-hoc processes that falter as companies grow.

There inevitably comes a time when leaders must introduce structure and procedures to enable their company to scale. If they overdo it, they run the risk of adding unnecessary bureaucracy. But if they do nothing for fear of losing flexibility or screwing up what already works, the problem only gets worse.

Over the years, I’ve worked with and observed dozens of companies that hit a wall because they didn’t recognize the signs of growing pains or failed to take action to improve the company’s scalability. Here’s some guidance that will help you navigate the fine line between chaos and bureaucracy:

First, Learn to recognize the signs. Dysfunctional decision making, miscommunication, and goal misalignment are all signs that a company’s processes are not keeping pace with its growth. Here are just a handful of examples:

• Persistent and disruptive strategy changes without key stakeholders present.
• Constant debate over critical issues with no real resolution or agreed-upon plan.
• Plans are agreed upon but some groups follow them while others don’t.
• Sales says customers want A, marketing requirements say B, product development is designing C, manufacturing is planning for D.
• Product gluts or shortfalls due to inaccurate and unreliable forecasting.
• Miscommunication between management levels, i.e. middle managers are constantly blindsided by “new” information, plans, decisions from above.
• The same as above but in reverse, between geographies, etc.
• Consistent budget misses in either direction.
• Support organizations like HR and IT are constantly overwhelmed.

Second, improve processes without adding bureaucracy. This is where the rubber meets the road and yes, it’s more art than science. Here are five artful tips:

• Don’t fix what isn’t broken. If everything’s humming along just fine, i.e. you’re not seeing the above signs, leave it alone. Take it process by process as opposed to an across-the-board overhaul.
• Make all key stakeholders part of the change process. Don’t impose procedures on key stakeholders without giving them a chance to weigh in and approve the change. We’re not talking lip-service here; we’re talking “integral part of the process.”
• Never add procedures because a consultant or some other disinterested party says you should. Always challenge the risks-benefits potential of any change.
• Think evolutionary change versus revolutionary change. If you keep that concept in mind, it will help you improve your processes without losing the entrepreneurial cultural that got your company to where it is in the first place.
• Change is significant; don’t outsource it. Entrepreneurs need to understand that change is necessary and significant. Don’t be afraid of it and don’t outsource it. Instead, embrace it, respect it, get ahead of it and lead. That doesn’t mean you shouldn’t seek outside expertise, just don’t let it get out of control.

Tech Leadership

WSJ Article

This needs to be read ...

Leaders Aren't Being Made At Tech Firms
posted by Soulskill on Sunday September 05, @08:15 (Businesses)
https://tech.slashdot.org/story/10/09/05/0141205/Leaders-Arent-Being-Made-At-Tech-Firms |

theodp writes "In this article Vivek Wadhwa laments that [0]short shrift is paid to management training these days at many high-tech firms. You can't be born with the skills needed to plan projects, adhere to EEOC guidelines, prepare budgets and manage finances, or to know the intricacies of business and IP law, says Wadhwa. All this has to be learned. Stepping up to address the problems of 'engineering without leadership,' which may include morale problems, missed deadlines, customer-support disasters, and high turnover, are programs like UC Berkeley's [1]Engineering Leadership Program and Duke's [2] Masters of Engineering Management Program, which aim to teach product management, entrepreneurial thinking, leadership, finance, team building, business management, and motivation to techies."

Discuss this story at:
http://tech.slashdot.org/comments.pl?sid=10/09/05/0141205

Links:
0. http://techcrunch.com/2010/09/04/tech-industry-managers-little-men-in-big-shoes/
1. http://cet.berkeley.edu/professional/engineering-leadership-program
2. http://memp.pratt.duke.edu/

6 attributes for Agile People

http://www.stickyminds.com/s.asp?F=S16277_COL_2

Agile coders are people who ...

1. Desire to collaborate
2. Freely ask for help
3. Are willing to take small steps and get feedback
4. Can recognise "good enough for now"
5. Can adapt as the circumstances change
6. Can offer to help in an unfamiliar area

5 Architectural Considerations

[IEEE Software May 2010]

Buschmann, Henney

Architectural design is involved with making good high level design decisions. These decisions are selecting a 'good' option from a menu of viable options. Such decisions are improved when the following considerations are made :

Economy, Visibility, Spacing, Symmetery, Emergence.

Economy

Less code is better than more code. Don't over engineer. Recognise the essential, recognise the incidental. Don't focus on re-usability if it's not required. Simple interfaces, adhere to patterns if possible, but make an economic choice that "balances clarity, compression and abstraction. Clarity is achieved by reducing clutter, compression relates to the directness of design and abstraction relates to the removal of unwanted detail."

Visibility

The architecure, design decisions, mapping of the problem space to the layers of design should be visible. Perhaps obvious - so obvious that the architectural framework can not be mis-understood or ignored. This reduces architectural abrasion over time, and reduces learning curves. No design decision should be implicit, hidden.

Group associated things (good objects ?)

Use correct names for objects, types, variables, services, ...

Patterns that help with clarity are : Explicit interfaces, Strategy, Value Objects (??)

Spacing

Separation of concerns. Separation of design concepts. Layers ...

Prefer hierarchy separation and composition to (multiple ?) inheretance.

"Delegation through conceptual roots expressed as pure interfaces leads to a stricter, more separated layering."

• Functional responsibility separation => components
• Component usage perspective separation => role-specific interfaces
• Componnt group separation => layers and sub-systems
• Separation between contract and implementation => explicit interfaces and implementation choice possibilties
  
• Separation of commonalities and variabilities => stable frameworks, with well defined plugin concepts (i.e. flexible ?)

Too much spacing becomes un-economic, and hides the wood with trees.

Symmetery

Symmetry is obvious, and simple to understand ... we can make reasonable predictions when symmetry is visible. We can expect consistency, alignment and balance - especially of opposites.

Examples:

• Object creation routines should be balanced with object destruction routines.
• Resource allocation and de-allocation (release)
• connect and disconnect
• open and close

The symmetry should occur in a localised space, be that a layer, function, object, ...

There are, however, many cases where the asymmetry of the external context is best represented asymmetrically.

Emergence (self-organisation?)

I'm not sure I've understood all this section, but a central theme is to devolve control from a central manager, down towards general workers (threads). This inverts the design problem from "how is the workload divided into chunks that can be accomplished by simple machines?" to "how can I assemble simple machines that can work autonomously on chunks of the problem, and achieve the solution?"

The above set of considerations are NOT rules or fundamental principals, just points of view to assist in enumerating and evaluating design options.

Cross Referencing Considerations

• Symmetry is both bounded and revealed by economy
• Emergency is bounded by visibility, and in tension with visibility
• Spacing is reinforced and reduced by economy
• Visibility is balanced by spacing and restrained by economy
• Economy can reveal emergence and vice versa
• Emergence and symmetry both contradict and align
  

Multitasking does not work

By Queena Lee-ChuaPhilippine Daily InquirerFirst Posted 17:15:00 06/06/2010

Filed Under: Education, Science & Technology,

Booch and Architectural Reviews

Why ?

• Stakeholders (paymasters) will want to see that the significant design decisions properly address their quality requirements and the business value creation needs.
• It is valuable and educational to compare the existing design decisions with architectural alternatives
• It is necessary to (identify and qualify) triage and fix what is broken.

See SEI ATAM method.

How ?

• Identify the forces that act on the system under developement
• "Grok" the system's essential architecture (essential versus accidental)
• Generate scenarios that exercise these forces against the architecture
• Throw the architecture against the scenarios - see what distorts.
• Ask hard questions
• Don't go down rabbit holes
• Follow the smells and press on the system's tender spots
• Keep it civil
  

Notes:

Review should be cheap, and periodic.
The architecture is not always readily available. A shared language is required, shared views and understanding. At least a list of significant design decisions is required.
People colour the reality they present based on where they wish to go.
A review can become emotive, empassioned, this can be a good sign. Expect grit, drama, avarice as we are human.
Assure that architectural diagrams/models are real - review naked code with architecture.

Meetings ... dying ?

http://www.forbes.com/2010/04/12/social-networking-chat-technology-cio-network-meetings.html

Perl Script to assess stability of a home ISP service

#!/usr/bin/perl

## app to log the availability of WAN items

$SIG{INT} = \&tsktsk;

use Getopt::Std;
use vars qw/ $opt_f $opt_q /;   ### runForever, runQuiet,
getopts("qf")  die "Please check options";

my $bell    = "\a";
my $MaxRecs = 90;

print "Ctrl-C to dump last $MaxRecs records\n";
print "Options: forever:$opt_f  quiet:$opt_q\n";
if ($opt_q)
{
    $bell = "";
}

use Net::Ping;

my $p = Net::Ping->new("icmp", 2, 128);
## my $q = Net::Ping->new("syn", 2, 128);   ## ?

my $router      = '192.168.1.1';
my $isp         = "82.39.210.1";    ##  Virgin Gateway : Katie's was "82.39.226.1"
my $dns         = '194.168.4.100';
my $bbc         = '212.58.244.141'; ## 'www.bbc.co.uk';
my $google      = "www.google.co.uk";  ## www-tmmdi.l.google.com   [66.102.9.99]

my $count       = 0;

my @hosts       = ($router, $isp, $dns, $bbc, $google);
my @history     = qw( FIRST );

open(my $fileH, '>>', "pingTests.txt") or die $!;

use IO::Handle;
$fileH->autoflush(1);
STDOUT->autoflush(1);

($s, $m, $h, $d) = localtime() ;
$line = sprintf "%02d %02d:%02d:%02d    RTR  ISP  DNS  BBC  GGL\n", $d, $h, $m, $s;

print $fileH "\n\nRESTART\n\n".$line;
print $line;

while (1)
{
    local $line;
    local $failed;
  
    ($s, $m, $h, $d) = localtime() ;
    $line = sprintf "%02d %02d:%02d:%02d    ", $d, $h, $m, $s;
    $failed = 0;
    foreach (@hosts)
    {
        $ok = $p->ping($_);  ## ($ok,$rtt,$ip) = ..
        if ($ok)
        {
            ##print "$_: $ok [$ip] ACKed in $rtt seconds.\n";
            $line .= "Ok   ";
        }
        else
        {
            ##print "$_: $ok [$ip] FAILED.\n";
            $line .= "Fail ";
            $failed = 1;
        }
    }

    if ($failed)
    {
        print "\n".$line."\n".$bell;
    }
    print $fileH $line."\n";
  
    push (@history, $line);
    if ($count>$MaxRecs)      ## keep a history of most recent reports
    {
        shift (@history);
    }

    printf "%04d %02d:%02d:%02d  ...\r", $count, $h, $m, $s;
  
    sleep(2);
    $count ++ ;
}



sub tsktsk {
    $SIG{INT} = \&tsktsk;    # Signal Handler''
    my $index = 1;
  

    warn "Ctrl-C\n";
    ## print @hosts;

    ($s, $m, $h, $d) = localtime() ;
    $line = sprintf "%02d %02d:%02d:%02d    RTR  ISP  DNS  BBC\n", $d, $h, $m, $s;
    print $line;

    foreach (@history)
    {
        printf "%03d %s\n", $index++, $_;
    }

    if ( ! $opt_f) ## == ! $runForever
    {
        $p->close();
        exit (0) ;
    }
}

Post Agile Status ...

http://gwaredd.blogspot.com/2010/02/game-development-in-post-agile-world.html