Wednesday, November 29

Agile Project Management With Scrum

Just read Agile Project Management with Scrum

Ken Schwaber gives lots of case studies in this. He is not afraid to use his own mistakes as examples to highlight the fact that scrum is a learning process.

I liked the 'Scrum is art of the possible' sound bite.

He uses case studies grouped by theme to illustrate proper use of scrum practices topped off with a series of lessons learned sections to nail his points down.
 
Update:  

Related Post

Related Information  


Tuesday, November 28

Started Reading Extreme Programming Explained

With all the detailed information about Extreme Programming on Ward Cunningham's WikiWiki and other sources reading Kent Beck's Extreme Programming Explained never seemed urgent. However I decided that it was about time I went to the primary source.

 


So far it is quite different from what I have read from other sources (many of which seem to have been based on the first edition). It has a loose style sometimes wandering off topic. However the first sentence grabs your attention. "Extreme Programming is about social change". After more than 10 years experience in the industry I can tell you that it is hard to underestimate the importance of the human factor in software development.

The neglect of this human factor in traditional approaches and the emphasis of it in agile approaches is what attracted me to agile in the first place.

Update:  

Related Posts

    Friday, November 24

    Talk on DotNetNuke on the 28 Nov

    V ICTORIA . NET DEV SIG - 28th November

    Enterprise Development of Dot Net Nuke Modules Part 2 by Philip Beadle

    Topics covered
    • How to use TFS Source Control with DNN Web Application Modules
    • Using Team Build to create installable DNN Modules
    • Unit Testing DNN Modules
    • Using nDoc (for ASP 2.0) to create your documentation
    • Writing a Test Script for your module
    VICTORIA . NET's mission for members in the Middle East - a great business opportunity by Peter Halliday & Maria Papadopoulos
    Topics covered
    • GITEX highlights
    • MMV support
    • Business leads

    Update:  

    Related Posts

    Related Information  

    Benefits of Courage

    Developers face many challenges in the workplace, but one of the most insidious is fear—fear that quietly undermines progress, communication, and quality. It can drive  hesitation, silence, and inaction.  

    Fear of Breaking the System

    You know something needs to change, but you're afraid that change will break something else. This fear is not unfounded—complex systems often behave in unexpected ways.

    Agile practices help. Automated tests—both unit and functional—combined with continuous integration provide a safety net. They allow developers to make changes with confidence, knowing they’ll catch regressions quickly.


    Fear of Admitting You Need Help

    You hit a roadblock. It’s taking longer than expected. But instead of reaching out, you stay stuck—worried you’ll look incompetent.

    Agile practices encourage support. Pair programming and daily stand-ups create regular, low-friction opportunities to raise your hand. But even with these practices in place, it’s vital to foster a psychologically safe environment, where asking for help is seen as professional, not weak.


    Fear of Challenging the Status Quo

    Sometimes the fear is political. You know the approach being suggested has failed before. But do you speak up? Or stay silent to avoid conflict?

    Agile adoption itself takes courage. Whether it’s speaking truth to power or suggesting new ways of working, being honest about risks and past learnings requires tact—and bravery. Managing upwards is part of the job.


    Fear of Saying No

    The timeline gets shorter. The scope stays the same. You know it’s impossible—but saying “no” feels confrontational.

    Agile encourages transparency. Velocity, burn-down charts, and scope control make trade-offs visible. But someone still has to raise the flag and say: if we cut the time, we must cut the scope. That takes courage.


    What Other Fears Have You Faced?

    These aren’t the only fears developers encounter. What have you seen? When did courage make a difference in your work—or when did the lack of it lead to trouble?

    Related Posts

    Thursday, November 23

    Benefits of TDD


    A fter the e-Commerce SIG talk I started chatting with a fellow attendee. We talked about what was not covered by the presentation.

    The conversation drifted toward Test Driven Development (TDD)  —and for good reason. To my mind, there are so many benefits that it’s hard to pick a single winner.

    But TDD isn’t for everyone. If writing tests before writing code feels too extreme, or if you’re working with legacy code that has no tests at all, don’t let the ideal of test-first stop you from writing any unit tests. Start where you can. Something is always better than nothing.

    Here are just a few of the benefits of writing unit tests:

    Confidence Through a Safety Net

    Unit tests give you the confidence to make changes, knowing that regressions will be caught early.

    Pressure to Break Dependencies

    When a module is hard to test, that’s often a clue (a code smell): it has too many dependencies. Testing encourages better separation of concerns.

    Better Object-Oriented Design

    Poorly designed code is hard to test. Unit tests push you toward cleaner, more modular, and more cohesive components.

    External View of Your Component

    Writing tests helps you see your code from the caller’s perspective—which naturally leads to more intuitive APIs and usage patterns.

    Now, ramp that up with TDD—writing the test first—and you get all of the above, plus some added magic:

    Focus on What, Not How

    Starting with a test forces you to clarify what you’re trying to achieve, instead of diving straight into implementation details.

    Discover Code That Already Works

    Sometimes you write a test… and it already passes. Why? Because the system already has that behavior.
    This has led me to delete large sections of legacy code that were—frankly—doing nothing useful.
    (It’s both satisfying and depressing.)

    Stick to What’s Needed

    TDD discourages speculative code. You implement only what the test demands—not what you think might be needed someday.

    The Biggest Benefit

    Ultimately this may be a shift in mindset.


    What About You?
    What other benefits have you experienced with unit testing or TDD?
    What helped you start—or what’s still holding you back?


    Update:  

    Related Posts

      Related Information  

      Agile Development Talk

      I just arrived back from the Agile Development Talk that the ACS e-Commerce SIG put on in Melbourne.


      The presenter was Martin Bauer who has been managing projects using FDD (Feature Driven Development) for 6 years.

      He talked about XP and Scrum as well as FDD. Unfortunately he did not know much about either XP or Scrum. He was on much firmer ground with FDD.

      He did not cover many of what I considered the greatest benefits of agile practices. He did cover the reduced risk of failure and he did emphasize the importance of the human element.

      The organizer suggested getting detailed requirements up front and an IID (Incremental and Iterative Development ) version of Waterfall.

      I told him that requirements were like pornography, the client knows what he wants [the requirements] when he sees it.

      It got a laugh.

      I not sure were I stole that from. Perhaps a kind reader could tell me who originally said it.

      Update:  

      Related Posts

        Related Information  

        Wednesday, November 15

        Agile Estimating And Planning

        The speaker at last nights  Melbourne eXtreme Programming Enthusiasts Group meeting reviewed Agile Estimating and Planning by Mike Cohn.


        He attended a course run by the author. The speaker showed everyone planning poker cards that Mike Cohn gives out. They were a big hit.

        Update:  

        Related Posts

          Related Information  

          Melbourne XP

          Attended the Melbourne eXtreme Programming Enthusiasts Group (MXPEG)p  last night. The topic discussed was Estimating XP stories.


          The conversation was driven by a newcomer to the group. She managed to get a lot out of the group by focusing on the groups collective experience of XP.



          Update: