Skip to main content

  • Three Interests causing alienation and a leadership vacuum by @aritikka

    • Small batches fully done


      This is The Way to reduce complexity, to enable measurability,
      control and agility       to the organization. This is a Lean revolution,
      dramatic change owned, driven and personally needed by the top management.

    • Please differentiate between competence and roles!

    • 3 more annotations...

  • Six Sigma and Agile Software Development (do they mix?)

    • We have successfully utilised the Six Sigma problem solving methodology DMAIC
      (Define, Measure, Analyse, Improve and Control) within each iteration to improve
      the reliability of the software development process. The key to the success of
      this methodology is its focus on using data-driven tools to identify what is to
      be changed and then to monitor the actual impact of changes in a feedback loop.
    • Agile methods use an iterative approach to ensure that flexibility is an
      inherent component of the project however this can lead to a lack of clarity as
      to whether the deliverable is tracking to goal. By applying Six Sigma concepts
      of defining, quantifying and measuring key delivery factors we can monitor
      overall delivery and quality of the resulting software without resorting to
      “analysis paralysis” in the early stages.
    • 1 more annotations...

  • Software Testing and QA Blog: Quality with Agile Webinar - 19 August 2009

    • This webinar looked
      at how to maintain quality in an Agile environment including examining the
      typical pitfalls, common practices and examples.
    • The role of the tester in an Agile implementation is to bring professional
      expertise in test and quality to the team. However, many Agile implementations
      struggle to implement effective approaches that achieve productivity
      enhancements with the required level of quality.

  • Unhappy with Agile … revert to Waterfall. Is this really The answer?

    • I recently noticed a question on a distribution list that I have seen and
      experienced so many time before. A team tried the “Agile” community, failed and
      plans to move back to another methodology, such as  the prescriptive CMMI
      or Waterfall, claiming that the processes are proven, reliable and will take
      them on the road of success. Personally, it may be years of experience in the
      trenches or hard learnt lessons learnt (I have a few project scars), I do not
      believe any of the defined methodologies will lead any team to certain victory.
    • At the end of the day there are no oracles in the world of Software Development
      Lifecycles (SDLC) and Application Lifecycle Management (ALM), there are no
      silver bullets and there is no methodology better than the other. What makes a
      methodology a success is the team than embraces it, using it as a supporting
      framework to promote stability, predictability, information sharing and using it
      as an aid, not as a solution.
    • 4 more annotations...

  • Dennis Stevens on CMMI and Agile - Decomposing Agile

    • In my post yesterday I talked about the Big Agile Capability Model.  I
      received comments ranging from “We don’t need processes in Agile” to “CMMI
      already supports Agile”. I actually agree with both of those statements. We
      don’t need a highly detailed task list that doesn’t allow for flexibility or
      creativity in the creative steps of building software. In fact, we need an
      approach that allows for a lot of interaction. But we do need to work with
      intention – we don’t need to be reinventing every interaction every time.
       And while CMMI does support Agile, it doesn’t look or sound like anything
      Agile people talk about. It hasn’t historically resulted in Agile behaviors
      developing within development teams. I believe that the very approach of
      implementing processes with complex names so that are auditable results in
      behavior that is contrary to the Agile approach.
    • To walk you through our process, we are basing our model on a decomposition
      Scrum and XP.  We look at the common roles of Product Owner, Scrum Master,
      and Team and identify the capabilities that typically are the responsibility of
      each role. The names and descriptions of the capabilities will be massaged some
      as we receive feedback and fine-tune our approach. But essentially, these are
      the capabilities that exist on most successful Agile teams today.
    • 1 more annotations...

  • Agile-Lean Benefits Standards and Models

    ©2009: Masa K Maeda
    President, Shojiki Solutions, Campbell CA USA
    www.shojiki-solutions.com
    Introduction
    Between January and May of this year I had the opportunity to give 17 presentations on Agile-Lean at private industries, government and academia.With only one exception a question I was consistently asked was: how can an enterprise that must keep compliance with a standard or that follows a model
    also use agile-lean, are they compatible? That’s a very important question because on the one hand most industries in Latinamerica follow either of those kinds of governance, and on the other hand there’s the impression that agile-lean is not compatible with those kinds of regulations and therefore cannot be adopted by them. This article’s objective is to put in perspective the benefits of adopting agile-lean at such enterprises.

    www.shojiki-solutions.com/...efitsStandardsAndModels_En.pdf - Preview

    agile lean cmmi iso9000 on 2009-09-06

  • Agile is a giant leap for software development

    • appropriate use of a suitable agile development process actually protects the
      desired level of quality and increases the likelihood of achieving this more
      than the linear/waterfall processes
    • So why has agile development created this perception of poorer code? The answer
      is quite simple: in the rush to be pragmatic, reactive, responsive and quick,
      there is also the need to be very disciplined - just like the programmers on
      Apollo 11 - and this doesn't always happen
    • 2 more annotations...

  • NOOP.NL: So, Now You're an Agilist... What's Next?

    A12 laws of software development by Jurgen Appelo. Great photos, intriguing ideas.. Wo
    rth checking

    www.noop.nl/...ure-an-agilist-whats-next.html - Preview

    on 2009-04-10

1 - 20 of 54 Next › Last »
Showing 20▼ items per page
List Comments (0)

Sponsored Links

Ads by Google