• 19Nov

    Scrum# - Using Lean Principles to Extend Scrum

    Agile, General, Lean, Process Improvement, Videos 2 Comments

    In my last post I discussed some of the issues why Scrum projects were failing. One of the reasons expressed by the interviewees was that organizations are trying, but failing, to extend Scrum across the Enterprise.

    Scrum is, like other Agile methodologies, primarily aimed at development teams on a project by project basis and is difficult to extend. This is where Lean principles can help.

    A few organizations have noticed the natural paring of using Lean techniques to extend Scrum (or Agile) principles. One such organization is NetObjectives. Their ‘Scrum#’ methodology (their version of Scrum guided by Lean principles) helps to define the gap between bottom up Scrum practices and top down Lean principles to help other organizations successfully implement these practices across the enterprise.

    After reading their whitepaper on Scrum# I was intrigued to find out more. I caught up with Alan Shalloway (CEO of NetObjectives and a thought leader in this area) to discuss more about this and discuss several scenarios where Scrum# can be beneficial.

    As a side note, their resources site is one of the best I have come across with information regarding Lean and Scrum. Not only do they upload articles and papers frequently, but also include free previews of work in progress books they are planning to publish in the future.

    Tags: , , , ,

  • 18Oct

    Scrum Is Not A Silver Bullet!

    Agile, General, Lean, Videos 4 Comments

    At Agile and Development conferences this year some sessions have been looking at how to improve Agile techniques using failed projects as examples. Discussing some of these issues and reading blogs and articles it appears that a significant percentage of Scrum projects have failed and it is not quite the silver bullet many expected it to be.

    In this weeks video blog I asked some of the leading Scrum experts (Dan Rawsthorne, Alan Shalloway, Sanjiv Augustine and Ken Pugh) what they thought the most common reasons for failing Scrum projects is and what advice they can give to resolve this. In their opinion, it appears management and managing the Product Owner are currently areas to improve upon.

    I believe that many organizations that practice Agile techniques do not strictly follow Scrum, XP, Crystal or any of the other flavors of Agile directly, but instead adopt a hybrid ‘Agile-esque’ practice using parts of these methodologies that they feel work best for their projects. This was reiterated at Bob Martin’s keynote at Agile 2008 where he also stated that ‘Agile’ will be the term used as a practice rather than the umbrella for the individual practices such as Scrum, XP etc. Will this see an increase in Project success? Only time will tell.

    One opposing theory is; teams will adopt whatever practices they can implement easily and quickly to comply with senior management edicts so they can claim their organizations are ‘Agile’ (whatever that means to them?!?). The reality is, underneath they will really be working in a Waterfall manner with little change to project success.
    Such proponents of this theory will state that only by following the practices strictly, can you achieve project success repeatedly (as demonstrated by Menlo Innovations).

    Tags: , ,

  • 07Oct

    Breaking Brooks’s Law

    Agile, General, Process Improvement, Software Quality, Videos 3 Comments

    Fred Brooks’s law of ‘adding manpower to a late software project makes it later‘ is one most of us have tried to prove wrong…….and failed!
    I was at Agile 2008 and saw an interesting session, “Breaking Brooks’s Law” from Menlo Innovations, a Michigan based Java development company. They claimed to disprove this law and demonstrated their working environment and techniques that allowed them to do so.

    Although the presentation was only 45 minutes, we were in the room for almost 2 hours asking questions to determine how robust their techniques were, and to gain more insight into the conditions developers work under.
    Menlo’s results are based on a 3 year project that the customer had a deadline to demonstrate at a show. More features were required for the show than currently in the plan. So rather than re-prioritize, Menlo decided to add more developers to attempt to complete the work. They managed to complete the Project on time with all added functionality.

    The environment at Menlo is quite unique. All developers are co-located in the same large room (no offices or cubes) and pair program 100% of the time - they follow strict XP practices. A scheduling team determines which projects developers work on and who they pair with on a weekly basis. So developers work with different team members and possibly different projects every week.
    Also, as part of the contract, the customer comes to Menlo every week to prioritize the work for the next sprint.
    These techniques may appear somewhat draconian (for example 100% paring). I managed to catch up with the team and interview them to discuss this project further, bug rates, staff attrition rates and how Project Managers can push the message of pairing to Senior Managements/Directors (see video).

    I thoroughly enjoyed talking with the team from Menlo and they invite anyone passing by to stop in and take a look at how they operate. They also have an interview process which involves a large number of candidates performing a number of tasks including Pair Programming, with an appointment you can observe this too. A detailed paper about their techniques and contact details are here.

    Tags: , , , ,

  • 15Jul

    More on ‘Best’ Practices & The Dreyfus Model With Dan North

    General, Videos No Comments

    Two of our recent blogs; The Misnomer of Best Practices and The Dreyfus Model are tied together nicely in this episode of Enerjy.tv by way of a conversation I had with Dan North of Thoughtworks.

    Dan regularly speaks and blogs about these topics and gives his views on where so called Best Practices should be in an organization and how they are used depending on your position on the Dreyfus Model. Dan gives examples of how developers use Best Practices when starting a new skill or position within a company and how these practices and rules diminish in importance and become a hindrance once skills levels rise towards the Expert level.

    Tags: , ,

  • 17Jun

    The Dreyfus Model - Back In The Spotlight?

    General, Videos No Comments

    The Dreyfus Model shows the 5 stages of skill acquisition possible through experience of a subject.

    Created by Hubert and Stuart Dreyfus in 1980 while researching AI, the model was popularized by Dr Patricia Benner in the mid Eighties in her work on the Nursing Crisis in the US. Over the last few years this model has been resurrected in the Software Industry, primarily by Andy Hunt of Pragmatic Programmer fame. 

    The graph shows that in the Software Industry (as with all subjects), most people achieve a level of ‘Absolute Beginner’ or ‘Competent’, with few moving to ‘Proficient’ and fewer to ‘Expert’. The graph also reflects that as you move up the model the need for rules and best practices diminishes to the point where they actually become a hindrance.

     dreyfus.gif

    With the huge shortfall in supply of Software Developers combined with the quality issues our industry faces, surely it is better to keep the small percentage of people at the top of this model rather than move them on to management? (As so often happens.)

    I caught up with Andy Hunt at the recent Better Software Conference to ask him to discuss this and explain further how this model applies to mentoring team members and where ‘best practices’ fit.

  • 19May

    Book Review & Video: Emergent Design by Scott Bain

    Book Reviews, Process Improvement, Software Quality, Videos No Comments

    The first page of the preface of this book made me wince! Not because the book is bad, far from it! The immediacy of Scott’s insight into the pain of software development can only come from someone who has been there and experienced the trials and tribulations of project failure (more than once).

    I was expecting this to be yet another book on Design Patterns, but it really isn’t. This book attempts to look deeper into questions that cannot be easily answered and suggests a road map to evolve the profession of software development. It concentrates on practices, principles and disciplines that developers should follow when creating software, especially when thinking about how to implement features. It covers a wide range of practices, including analysis, refactoring, testing, and looks at how existing patterns should influence our design decisions.

    The appendix includes some very good examples of common design patterns. Different styles are applied to each pattern to teach or remind us what type of problem each pattern is used for. UML diagrams, procedural code alternatives, non-software analogies and basic OO code for implementation are included for each pattern.

    Since so many of us have to deal with legacy code bases, it’s always helpful when a book like this addresses that issue. Scott mentions hearing comments such as “this code is too hard to unit test,” “unit testing takes too much time” and “too many permutations to unit test.” He explains how these all point to design issues, and that leads into a great chapter discussing refactoring.

    Why should we refactor if the behavior does not change? This and other similar questions are covered too, explaining the concept of technical debt and the frequency of developer burnout: “Decaying, hard to maintain software will disable a development team faster than anything I know.”

    I would thoroughly recommend this book to any developer, however experienced or inexperienced, who wants to understand more about design patterns and how thinking in a design-driven manner can evolve our profession.

    I caught up with Scott at SD West, to ask him a few questions about his book.

  • 07May

    Video: New Features in Java 6

    Videos No Comments

    With JavaOne commencing this week, there will be much persuasion for those not yet upgraded to Java 6 to do so.

    Although not as rich in features as the move to Java 5 was, Java 6 still has benefits. My favorites include:
    - A scripting engine (Rhino) for languages such as Javascript
    - Wildcard inclusion in Java classpaths
    - JTable sorting, filtering and highlighting in Swing
    - Zip files no longer have a limit on entries (was 64k) and include long filenames
    - Java DB included (based on Apache Derby) with support for JDBC 4
    - GIF support for image I/O
    - A limited HTTP Server

    A few nice API additions include:
    - Deque (Double Ended Queue), intended to replace Stack in the Collection Framework
    - NavigableSet and NavigableMap, ideal for dictionary types
    - Methods such as getFreeSpace() and getUsuableSpace() available on drive partitions

    Performance improvements have been seen on certain environments such as JBoss running on Linux, just by upgrading to Java 6.

    For a full list of enhancements see this.

    I spoke with Jason Hunter about some of these new features, Java’s popularity and the much-debated issue of including Closures in Java 7. Here are his thoughts…

  • 23Apr

    Video: Cease Inspections

    Videos No Comments

    When investigating Lean for the first time, books and articles that give an overview of the principles and tenets of Lean can appear to be contradictory. For example many managers may question how Cease Inspections can be advocated where a basic principle of Lean is to Create Knowledge. Surely one of the fundamental reasons of Inspections such as Code Reviews is to help more Junior Developers adhere to company standards and learn better, more efficient ways to code?

    I discussed this further with Bob Martin (Uncle Bob) and Jean Tabaka and they gave some good insight into what this phrase ‘Cease Inspections’ really means, even with Jean’s radical conclusion of Firing your QA department ;-)

  • 08Apr

    Video: Small steps

    Videos No Comments

    When your manager says: “We expect you to write good quality code,” many people, especially junior developers, will freeze, thinking about code structure, performance, best practices, company coding standards, patterns… the list goes on and on.

    At SD West, I recalled David Bernstein’s advice when writing a class. He said to ask yourself the question: “How would I test this class?” If the answer is too long or complicated, then you need to refactor the class. That seems like a good starting point for someone who is not sure where to start.

    That led me to think that a good topic for Enerjy.tv would be to ask our panel of experts what one piece of advice they would give to developers when thinking about quality issues. So that’s what I did.

  • 31Mar

    Selling quality initiatives to management

    Videos No Comments

    Last week’s “Don’t Worry, Be Crappy” post focused on some managers who may push for a quick release in place of quality initiatives. Most developers believe that these goals are not mutually exclusive, and have ideas on how things could be done better. However, many are reluctant to even mention these ideas to their managers for a number of reasons including:

    1) The “this is how we’ve always done it” philosophy;
    2) They have seen management reject similar ideas in the past, and therefore believe they would be wasting time even bringing their ideas up;
    3) Intimidation or lack of confidence or experience to “sell” the idea to management.

    At SD West, I asked some of the speakers, who are also experienced developers and managers themselves, what advice they would give someone who has an idea and wants to sell it to their manager.

« Previous Entries   

Recent Posts

Recent Comments