Posts Tagged ‘agile bazaar’

Deep Lean Conference

November 11, 2007 1 comment

I attended the Deep Lean conference held at MIT on November 3 & 4 2007. It was an information-packed 2 days with Jeff Sutherland, Mary Poppendieck (with Tim Poppendieck contributing by answering some questions), and Nancy Van Schooenderwoert. Jay Conne (Current President of the Agile Bazaar) hosted and added to discussions.

The weekend covered the origins or agile software development (including many references to The Toyota Way), the cultural and mindset aspects, the techniques for optimal agile, business proof of why agile is best for software development, and great war stories from the field. There were many references given for further reading and study. There was some discussion about how CMMI fits with agile and how if an organization is praticing Scrum well it is already performing as a CMMI level 3 organization. I suppose this may be true in theory, but deserves looking at this carefully. The last session on Sunday was an open panel with many very good questions asked. I also had the opportunity to sit across from Mary Poppendiek at dinner on Saturday evening where I heard more interesting stories.

There were a few things that I thought were particularly interesting during the weekend.

  • 80% of the features delivered in a waterfall lifecycle are never used, therefore, in an agile lifecycle the 20% that are used are delivered first. Then you realize you are done and can sell it in 1/5 of the time.
  • Scrum needs to be applied to other parts of the organization, not just software development. For example, Sales contracts need to be crafted with the idea of time-boxed commitments and delivery with feeback expectations on a regular basis.
  • Executive planning and commitment measures (KPI’s) need to be consistent with time-boxed development cycles. You can’t have an agile lifecycle with waterfall measures.
  • Scrum (or any agile iteration) needs a cadence (see my blog entry ‘Agile Peak Performance in Early Startups’) to keep the stride of the engineering organization. Re-prioritization of stories and changes in the work to be performed must be planned for a following iteration so as to not disrupt the current iteration.
  • Retrospectives are great for reflecting on the iteration just completed, but process improvement in agile teams must be much more than that. It must include a “Kaisen Mind”: a stop the line attitude to fixing problems (defects and process) as they occur and regular reflection on things that need to improve for optimal performance and quality. Don’t accumulate technical or procedural debt.
  • Product Owner is a key role that requires the right person to both represent the customer, and be able to maintain prioritized stories that meet the objectives of the business and the timely needs of the development organization. Product Management still requires traditional Product Marketing Principles and should not be confused with the Product Owner role of breaking down the detail features and prioritizing them, even if both of these roles are the same person.

The speakers intentionally didn’t dwell on the mechanics of the Scrum Master or Product Owner, but did talk about the importance of these roles and did answer specific questions about these roles. I asked the panel “…with your experiences, do you recommend managing stories and tasks on paper cards, streadsheets, or an agile lifecycle management tool?” Jeff Sutherland responded that he always uses the paper cards and the traditional Scrum Board in the war room as the regular way of managing the work. He does use other tools, depending on the size of the project and how the teams are dispersed, but will generate cards from the electronic system for use in the war room.

In conclusion, I felt I got my $600 worth of the conference. I highly recommend this conference to leaders, managers, and executives who are either practicing or thinking about practicing agile lifecycles in thier organization. You will leave a believer, have a means for justifying making the move to agile, and have an arsenal of references to share and for further reading.


New England Agile Bazaar October Meeting

October 26, 2007 Leave a comment

I attended the Agile Bazaar meeting this month at Tufts University. This was a panel discussion format moderated by Ron Morsicato with an open format including a series of questions crafted by Ron that were geared towards adoption of agile practices. The panelists:

  • Don Roby, Cyrus Innovation. A developer of highly usable solutions with a proven blend of Agile programming techniques, user-centered design, and deep insight derived from the firm’s financial services experience.
  • Brad Kain, Quoin, Inc. A builder of sophisticated applications for media, publishing, retail, finance, life sciences, and other industries.
  • Giora Morein, BigVisible Solutions. A premiere provider of Agile enablement, training and software solutions.

There seemed to be consensus that agile practices are most popular in both small startup companies (especially in SaaS) and large financial services companies (like Fidelity Investments). The reason small startups are adopting embracing these practices is to address the rapid pace and reduction of technical debt. It is easier for these organizations to adopt agile because they can start fresh with this approach and don’t have the cultural overhead to limit the pace of change. The larger financial services organizations are adopting agile to address the management of many small projects as opposed to most service and product teams.

There was a discussion about hybrid methologies and the experience the panelists have had in the field. Most organizations to not practice a specific methology but a collection of practices, and then give the collection a name specific to their organization.

  • Scrum or similar methods that describe the way in which projects are managed at the detail level, with a product owner.
  • Some subset of XP development practices, especially TDD (test driven development) – a lot of resistence to peer programming – very few are using the notion of an on-site customer.
  • Managing the business with CMMI or similar infrastucture framework is common with larger organizations, incuding phases and gates. There is evidence that CMMI is compatible with agile project management practices and certainly with XP coding practices.

Organizations looking to make the change to an agile lifecycle have common things they don’t want to let go of. For example, building narrow funtionality (through all tiers) and delivering often, logging and tracking all defects found after a coding phase, constant communication within a team, and the dreaded exposure of peer programming. Architects of web services need to have a vision for the tiers needed for the service, but unlike a waterfall approach where you can complete a majority of a tier before moving on the the next, only to portion of each tier relevent to a specific feature in scope for the iteration is developed. The challenge of the change agent is to let them use familiar tools in a different way that moves them to changing the practices. For example, working with QE at the time of development and treating most defects loosely as part of the development exercise, and only escaping (after closing a story) defects can be logged and tracked as before.

Offshore, nearshore, and collocated teams were discussed. There is contention with many companies as they seek to reduce overhead by utilizing outsourced development services. Most of the companies in India, Eastern Europe, and Canada move people from project to project often, keeping their signature engineers on strategically high profile projects, especially to win new business. They tend to resist agile project managment approaches and have cultural challenges with sharing perceived bad news. Giora talked about a survey he conducted for a company with teams locally, India, and Canada, which had a series of projects together. This survey included both quatitative and qualitative questions about their experiences. 83% said the most successful projects included personnel spending time in the other locations, suggesting that face time really makes a difference in the success of a project. These respondents also said that they preferred to be in the same time zone. However, Giora mentioned that one of the most successful projects included members of the team in India spending time in the local project teams and having development in both time zones had the effect of 18 hour days. There was no evidence of increased productivity though. There was also talk about setting up your own team in India if you want to use agile practices. We did not seem to come to any conclusions on making what makes an outsourced project work with agile.

Categories: Agile Tags:
%d bloggers like this: