Sunday, February 21, 2010

To Read

    Ken Schwaber on Scrum

    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.

    Saturday, February 20, 2010

    Sashimi Slicing

    Sashimi Slicing

    Ken Schwaber:
    Rowan Bunning:
    Kane Mar:

    Pair Programming Guidelines

    Uncle Bob's Scrum Shortcomings 7 Theses

    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?

    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?

    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;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

    Friday, February 19, 2010

    Wednesday, February 17, 2010

    Self organising teams

    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.

    Tuesday, February 16, 2010

    Emergent Design and Evolutionary Architecture - Neal Ford

    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
    - 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

    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

    - 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

    - 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

    - 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 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
    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.