To Read

• http://www.infoq.com/presentations/harrop-modular-webapps-with-osgi
• http://www.infoq.com/presentations/4-challenges-5-values
• http://www.jessefewell.com/2010/02/19/scrum-is-dead-long-live-scrum/
• http://blog.coryfoy.com/2010/02/they-could-have-been-contenders/
• http://blog.coryfoy.com/2009/08/is-the-certified-scrum-master-program-the-visual-basic-of-agile-development/
• http://agileconsulting.blogspot.com/2010/02/my-interview-with-scott-ambler.html
• http://www.ambysoft.com/essays/agileProjectPlanning.html
• http://www.agile-process.org/proverbs.html
• http://xprogramming.com/xpmag/whatisxp
• http://www.infoq.com/presentations/From-Concept-to-Product-Backlog;jsessionid=6CEB65FA46F487CB2CCF23AF0529CCC3 
• Usability/Agile: http://vimeo.com/9363846

• http://weblogs.asp.net/pgielens/archive/2006/05/31/Applying-the-Application-Layer-in-Domain-Driven-Design.aspx
• http://www.coderanch.com/t/100476/OO-Patterns-UML-Refactoring/Domain-Layer-dependancy-confussion
• http://community.jboss.org/wiki/HibernateinaLayeredArchitecture
• http://iamjosh.wordpress.com/2008/01/30/aspect-oriented-validation-in-java/

Ken Schwaber on Scrum

http://www.agilecollab.com/interview-with-ken-schwaber
(http://blog.coryfoy.com/2010/02/)

agilecollab: Are you pleased at rapid spread of Scrum?

Ken Schwaber: Yes, in that the spread means that people are desperate for a new approach. No, in that they may think of Scrum as simply an iterative version of waterfall. Many CIO’s still think of Agile as more, faster. However, as organizations and projects flee the existing controls and safeguards of waterfall and predictive processes, they need to recognize the even higher degree of control, risk management, and transparency required to use Scrum successfully. I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.

agilecollab: Do you agree with 50% Scrum approaches? Are there any dangers in this approach?

Ken Schwaber: Scrum is a very simple framework within which the “game” of complex product development is played. Scrum exposes every inadequacy or dysfunction within an organization’s product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.

agilecollab: What makes Scrum a good fit for using it with any engineering approaches like XP or even system approaches like Lean?

Ken Schwaber: Scrum is a framework. XP engineering practices can be used within a Scrum Sprint to improve quality and productivity. Lean is a way of thinking that optimized complex, repetitive processes. Product development is more of a one-off thing, where every release and project is more unique than similar. However, much of the thinking that Lean uses is also used by Scrum, so studying lean helps you understand Scrum. For instance, value stream mapping helps optimize some of the processes – such as change control – that aren’t addressed by Scrum. Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices – such as risk management. Scrum then shows you how well that approach works through transparency, so you can continually optimize the approach.

Sashimi Slicing

Sashimi Slicing

Ken Schwaber: http://www.agilealliance.org/system/article/file/970/file.pdf
Rowan Bunning: http://blog.softwarewithstyle.com/2009/01/29/mistake-2-exceeding-the-transition-speed-limit.aspx
Kane Mar: http://kanemar.com/2009/08/24/the-tale-of-the-overflowing-tea-cup/

Pair Programming Guidelines

http://www.extremeprogramming.org/stories/pair.html

Uncle Bob's Scrum Shortcomings 7 Theses

(http://www.infoq.com/news/2010/02/scrum-failings)
In response to a question asking about the inherent shortcomings of Scrum/Agile, Uncle Bob, wrote:

If we think about what scrum is as it comes out of the box, and not what scrum
should evolve into as a team adopts it, then the hindsight of the last decade
makes it pretty easy to spot some serious flaws.

1. No technical practices. Scrum is great at giving project management advice,
but provides no technical help for the developer. Any good implementation of
Scrum needs to borrow technical practices from some other method like XP. The
suite of technical practices that should be added probably include: TDD,
Continuous Integration, Acceptance Testing, Pair Programming, Refactoring.

2. 30 day sprints are too long. Most scrum teams have either shrunk them to 2
weeks or perform some kind of midpoint check at the two week mark. I know of
some teams that have two 2-week "iterations" inside a single 4-week "sprint".
The difference being that they use the sprint for reporting upwards, but use the
iterations for internal feedback and control.

3. The tendency of the scrum master to arrogate project management powers. This
is not a problem with Scrum out of the box so much as it is a problem with the
way scrum sometimes evolves. Perhaps it is related to the unfortunate use of
the word "master". Perhaps the XP term "Coach" might be a better word to use.
In any case, good implementation of scrum do not necessarily correlate scrum
masters and project managers.

4. The C in CSM is unfortunate. Again, this is not so much about scrum out of
the box as it is about the scrum community. That letter C has gotten far too
significant for it's intention. It is true that the people in a scrum team need
to be trained. One of the things they should be trained about is the role of
the scrum master. The problem with the C is that it changes the notion of scrum
master from a role into a person. It is the person who has the C. In an ideal
case, the members of the scrum team will rotate through the scrum master role
the same way the members of an XP team rotate through the coach role. This
rotation is never perfect, and sometimes the role sticks to one or two people
more than others. But the idea was never to raise up a particular person with a
rank. We never wanted that C emblazoned on their chests.

5. Scrum provides insufficient guidance regarding the structure of the backlog.
We've learned, over the years, that backlogs are hierarchical entities
consisting of epics, themes, stories, etc. We've learned how to estimate them
statistically. We've learned how and when to break the higher level entities
down into lower level entities. Epics->Themes->Stories->Tasks.

6. Scrum carries an anti-management undercurrent that is counter-productive.
Scrum over-emphasizes the role of the team as self-managing. Self-organizing
and self-managing teams are a good thing. But there is a limit to how much a
team can self-X. Teams still need to be managed by someone who is responsible
to the business. Scrum does not describe this with enough balance.

7. Automated Testing. Although this could be considered a derivative of point
1, I thought it worth calling out as a separate point because it is so
fundamental. Scrum doesn't mention this, yet it is the foundation of every
agile effort. Agile teams work in short cycles because feedback only works well
in short cycles. But short cycles aren't enough. You also need objective
measurement of progress. The most reliable way to know how much a team has
gotten done is to run automated tests and count the tests that pass.

8. Multiple teams. Scrum has little to say about the coordination of multiple
teams. This is not a failing unique to scrum. Agile itself is virtually silent
on this issue. Scrum talked about the vague notion of a "Scrum of Scrums" but
that idea really hasn't played out all that well. Scrum-in-the-large remains in
the domain of certain consultants who claim to have an answer. There is no real
consensus on the issue.

Questions for new Agile teams

BA/Product Owner
How will you split down the story cards?
How do you determine which has highest business value?
How do you plan to divide work into thin slices along lines that maximise the rapid delivery of business value?
How will you get and keep customers interested in trailling your product?

Devs
What Agile development practices will you use?
 - Bob Martin: The suite of technical practices that should be added (to Scrum) probably include: TDD,
Continuous Integration, Acceptance Testing, Pair Programming, Refactoring.
How will you introduce Agile development practices?

Manager
Are you prepared to invest time to see the practices take effect?
Schwaber estimates that 75% of organisations using Scrum will not succeed in making better software due to the higher degree of control, risk management, and transparency required to use Scrum successfully.

Agile Anti-Patterns

Mistake #1: Premature Process Optimisation

Mistake #2: Exceeding the Transition Speed Limit

Mistake #3: Misaligned Sashimi Slicing

Mistake #4: Accumulation of Undone Work

Mistake #5: Individual Heroics

Lessons from ECMAScript standards process

http://www.infoq.com/presentations/The-State-and-Future-of-JavaScript;jsessionid=E17A1DEBAF4CCA9BE772657C9A3077EE

Douglas Crockford (JavaScript Architect at Yahoo)
Lessons from ECMAScript standards process

Need a clear separation between research and standard setting - a standard is the last place where you want to see innovation.

If you have a great new idea - don't tell it to a standards body
Instead implement it then show it to the world, if the world agrees, then it can become a standard

Go For The Low Hanging Fruit

http://www.agilejournal.com/articles/columns/column-articles/275-go-for-the-low-hanging-fruit

1. Make a Change Backlog
2. Find the low hanging fruit
3. Establish a raiding party
4. Establish a success story
5. Go to war
6. Celebrate!
7. Start over 

Mutating State = Yak hair

bguthrie

  

Every time you mutate state, somewhere a baby yak starts growing hair. 

5:08 AM Feb 18th from Tweetie Retweeted by neal4d and 17 others

Self organising teams

http://www.agile-process.org/team.html

Highly productive self organizing teams are not easy they require discipline. Good leadership isn't doing what ever you want when ever you want. The team member with the least discipline has the most control by simply not following the process. You must set and meet team expectations at all times. Other team members must be able to trust you and know what to expect from you

Estimating features with shared code

Honest Plans
You want a single estimate for each feature represented in the product backlog. Customers must weigh the different options to find the most important things to do next. You can't burden them with such issues as dependencies. Put the cost of developing that feature and that feature alone on every story.

If building this feature lowers the cost of that feature then you have already designed some shared code. Separate technical decisions from requirements decisions by estimating each feature independently and as if that is the only feature you will build. If developing this feature still lowers that feature's estimate then lower the estimate only after this feature is working. Remember that you are creating a shopping list for people without technical backgrounds.

Emergent Design and Evolutionary Architecture - Neal Ford

http://tr.im/nf_ead_all

Agile vs Waterfall is not binary - spectrum
e.g. Pure Waterfall -> BDUF -> Some DUF -> Agile/Emergent Design -> Cowboy Hacking

BDUF is a lossy compression algorithm
486DX: FPU
486SX: broken FPU - not designed, emerged

iPod - have to buy new design - hardware can't be refactored

Software Design
finding abstractions & patterns
idiomatic patterns
- nomenclature - give it a name
- technical patterns - e.g. transactions handling
- domain patterns
patterns describe abstractions

Abstracting too early
- speculation w/- facts
- YAGNI
- Business processes change
- how do you know when to abstract?
-- experience helps
-- spike solutions

Emergent Design
What is software design
Jack C. Reeves = C++ Journal 1992
Software "engineering"
final goal of engineering is documentation, given to manufacturing team
what is design do in s/w?
- complete source code
source == design
software is cheap to build
manufacturing team == build process
cheapness leads to complex design

Emergent Design
discovering design in code
finding effective abstractions - techincal/domain
ability to harvest idiomatic patterns

Things that obscure emergent design
Complexity
- essential complexity (inherent) vs accidental complexity (externally imposed)
-- e.g. complexity spectrum: Hunting season -> field-level security -> EJB/Biztalk
-- accidental: "just in case"

Technical Debt
- Can't avoid debt but can negotiate repayment
- must convince it exists
- start conversation
- use demonstration, trumps discussion
- e.g. cyclo complexity chart

Rampant Genericness

Helpers
Test Driven Design
- more about design than testing
- design emerges from tests
- atomic understanding of intent
- better abstractions
- less accidental complexity
- test after doesn't expose design flaws as easily

Refactoring
- collective code ownership
- fix broken windows
- fix obsolescent abstracting
- prudently refactor aggressively
-- Tech Debt backlog if > 15 mins to fix
-- Pair just doing tech debt backlog
- code should get stronger with age

Cyclomatic Complexity
- e - n + 2

Afferent Coupling
- incoming references to class
- CKJM
- e.g. Struts param - couldn't predict complexity

Expressiveness
- complex languages hurt readability
- comments not executable, out-of-date
- idiomatic "unit of work" pattern
- Java - comand pattern vs Groovy - closure

Abstraction Styles
- imperative: structured/modular OO
- functional
- anti-objects: collaborative diffusion
-- The metaphor of objects can go too far by making us try to create objects that are too much inspired by the real world
-- e.g. "PacMan smell" - put the main computation into the maze

Application Architecture
- course-grained
Framework Level Architecture
- library
- JSR 277: abandonware
- JSR 294: superpackage, jigsaw, Java 7
Enterprise Architecture
- city planning
Application Architecture
- Building planning

Extant Definitions
- Architecture = stuff hard to change later - should be as little as possible

Architecture Considerations
- Politics
- Build or buy (myth)
- Most Business process are not commotitisable
- software = strategic competitive advantage

build/buy
- strategic/overhead?
- strategic - build
- overhead - functional/extensible? buy

Dietzler's Law
- 80% fast/easy
- 10% difficult
- 10% impossible
- user wants 100%

Standards-based vs standardization
- e.g. J2EE: good for devs, bad for vendors
- SQL standard very weak - good for vendors
- ESB not standardised - vendors don't want it to be

Irrational Artifact Attachment
- longer it takes to create an artifact (e.g. Visio diagram) more attached people become, less likely to change

Last Responsible Moment
- Do we have to make decision now?
- How can we make it reversible?
- How can we defer decision?

Agile projects from development to maintenance

A wikipedia article http://en.wikipedia.org/wiki/Agile_software_development suggests that Agile projects are better suited to often changing requirements, with teams of senior developers and Waterfall better suited to critical software with junior developers and little change in requirements.

What happens when the project that suits Agile in development finishes development cycles, enters support cycles and becomes a critical piece of software with few changing requirements and junior developers?  The software was built in the first place to withstand the pace of a team of senior developers adding features, ripping out features - a flexibility built into the team's way of implementing the software that could not be maintained by the latter team.  The latter team does not know how to change the software and dares not due to the complexity that was slowly built and understood in great detail by the former team.  When changes need to be made to the underlying infrastructure, they require much more effort.

Agile home ground:^[14]

• Low criticality
• Senior developers
• Requirements change often
• Small number of developers
• Culture that thrives on chaos

Plan-driven home ground:^[14]

• High criticality
• Junior developers
• Requirements do not change often
• Large number of developers
• Culture that demands order

http://www.agile-process.org/change.html
Berry Boehm found that as software proceeded through its life cycle the cost of making a change became larger. Ratios of 100:1 for making a change after delivery versus project start are common. But ratios as low as 5:1 can be found. How flat this curve stays depends on many individual project factors.

There are three life cycle events that seem to accelerate software rot.

• When we proclaim the design is done and accept no more changes. 
• When we move the system into maintenance and change the team's process. 
• Last when the cost of making vital changes exceeds our resources we reach the wall of unmaintainability.