We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Are "Agile" Practitioners Often at Odds with Architecture and Quality Engineering Teams?

Vote 0 Votes
iTKO: Are "agile" practitioners often at odds with architecture and quality engineering teams and why?

8 Replies

| Add a Reply
  • Agile has this fundamental principle of evolving architecture and quality over multiple iterations by staying nimble and focussed on working software. In my experience, this principle is NOT at odds with architecture and teams when the architecture is "straightforward". Like a classic 3 tier or 2 tier. For complex architectures (n tier, multi-channel), Agile simply does not work very well unless you have team members who have a level of experience to be "architecturally correct" in short cycles.

    With regards to quality engineering, I have always seen Quality teams WELCOMING agile with open arms since the builds are much more frequent and QE involvement starts early in the lifecycle. So I have not seen a situation when QE teams are at odds with Agile.

  • The answer depends on how smart the "Agile" Practitioners are. If they jump into agile development without observation of architectural horizon, they risk to end up at very sharp odds with Architecture.

    We do not need a frequent and prompt delivery of non-compliant code even if it has a label of Agile.

  • I think if the underlying 'business data model', by which I mean the data objects upon which the agile environments will operate, is fundamentally robust, I see no conflict with agile development environments which are generally targetted at the 'front end' or 'client side'. If the underlying data services are structured correctly and have good life cycle governance, in fact this can work well IMHO. I think as one moves closer to the core assets, one needs solid, stable implementations that I feel are at odds with an agile development methodology unless one is just building a prototype or proof of concept.

  • A typical software development cycle starts by capturing and analyzing business requirements and goals. A high level analysis of identifying major architecture artifacts consisting of high level service identification, interaction model, data model and EA blue print of SOA to meet business requirements is a necessary first step. With the iterative Agile process rolling up to a release is primarily focused on construction/build. The key to Agile process is pinning down the date at which we want completion for production or release, prioritizing functionality, identifying available resources and making major decisions about architecture. Many of Agile Scrum implementations creates an extra sprint (Sprint 0) to create architecture frame work and quality policy. Since Agile enforces only producing members as part of Scrum, the non producing members like enterprise architect or CQ might get left out if care is not taken to involve them right from day one. In my opinion, compared to more traditional methodologies the architecture/quality planning phase is kept short in Agile and care must be taken to allocate architecture/quality review times as part of each sprint. Fine tuning the release planning to interject architecture & quality reviews in the sprint process reviews will be the key to the successful delivery of a quality release that meets high technology standards as well as delivered in time

  • As with all things the answer is: it depends. Architects are usually the most difficult to sell on Agile because they rule the waterfall Design phase. After design there job on the project is mostly over. QA/QE are similar in that they own the waterfall Testing phase. They are used to receiving the coded project and then they play "lets create a bunch of defect reports". As Michael Poulin stated smart Agile Practitioners will spend quality time with the involved people and teams selling them on how they will basically do the same work as before but in a more distributed manner which benefits the company. Get them on board and success breeds acceptance.

  • As with all things, the support for Agile needs to come from the top. If you have some developers/architects attempting to institute Agile methods, and others locked into more traditional approaches, and management is absent on the issue, then, yes, there will be conflicts.

  • It depends on how agile is used. If agile is being used as an ad hoc exploration, then in my experience quality suffers.

    But agile does not equate to ad hoc.

    Clarity, governance, and visibility are the key issues. An agile project ought to have a business objective as its compass, and balance known and unknown parts of the overall picture/architecture. When used as a successive refinement of what is unknown, and with a clearly understood problem and business objective in mind, then quality is actually better.

    This is because Quality Engineering (QE) is not an afterthought with high risks. Team cohesion and visibility are the keys for this. Good architecture and quality have to be part of the agile team from day one. With the right early participation, interaction with customer and clarity of business objectives, QE provides a better insight into what the customer wants, and what the software does. As a result it can perform better.
    We have found that architecture and QE become the vital part connecting users and developers because a correctly-staffed Quality Engineering team is familiar with both worlds. Aligning user stories with formal tests scripts is a great way of ensuring this cohesion.

    Thanks to John Sotiropoulos, Metastorm Chief Architect and Senior Director of Product Innovation, for working with me on this response)

  • Kudos to Greg Carter for an excellent response. I only want to add a couple of thoughts to his reply. I would add two more critical success factors:

    1. It's key that Applications management teams ensure that QA and Architecture are participants on trusted Agile teams. In addition management needs to set as an objective to instill enough training and skills so that the full Agile team understands the implications of the architecture they are building within and the policies and standards they need to comply with as they work (and automated policy compliance checking during the Agile sprints can help as well). Secondly,

    2. Aligining User Stories with formal test scripts is a key success factor and also aligning them with policies as well will help identify and ensure that non-functional requirements around architectural compliance, standards and technical quality will be achieved.

    What I'm hearing here is that QA and Architectural Governance are not the antithesis of Agile but rather complementary and critical to the realization of solutions that hold together in the enterprise.

Add a Reply

Recently Commented On

Monthly Archives