SDLC – Software Development Lifecycle … agility strikes back with energy (part 4 of many)

Continued from our recent discussion, SDLC – Software Development Lifecycle … exploring common models (part 3 of many).

Agile Manifesto

Agile manifesto, quoted unchanged from https://www.agilemanifesto.org/

Agility on the  move

If you want to stir up a political debate in any organization, ask a room of people what agile development is all about. Typically the classic project managers do not like | trust agility, because instead of focusing to and enforcing change through a project plan, an agile team focuses on working solutions, rather than extensive documentation … and collaboration, not contractual and often bottlenecking negotiations. Whatever comes from the debate, it is important to realize that Agile is not a license to introduce an agile license to bend any process or solution to your liking, or to introduce a chaotic hacking environment!

The core objectives of agile engineering practices seem to include:

• Successful delivery of systems quickly
• Customer satisfaction
• Incremental and frequent software delivery, in the magnitude of weeks (preferred) to months
• Collaboration between business and software engineers
• Measurable and sustainable development
• Quality, quality + quality solutions

The agile teams are based on pillars of competence, common focus, self-organization and fuzzy problem resolution … no, not management or Swiss precision planning, but instead agility to react to fuzzy and changing requirements. My personal favorite agile process is SCRUM, whereby I have seen the implementation on some of its features rescue a doomed project, just by propping up the team members, releasing them from administrative hell, enforcing collaboration and most importantly communication amongst all stakeholders. You can read more at https://dotnet.org.za/willy/archive/2008/09/15/to-scrum-or-not-to-scrum-some-of-quot-my-quot-views.aspx, which outlines some of my personal views on scrum.

Agile processes … in a picture

If you are interested in more information on the TFS Scrum process templates, refer to “Light-Weight Scrum, eScrum and Conchango ... why three process templates?”. Also evaluate the all new Agile process template in Visual Studio 2010 (CTP2+) … some really exciting innovation and productivity making an appearance.

Why consider agility?

So why bother with agility, may be your question? Think of the way that the British forces fought against the Boers in South-Africa in the early 1900’s … while the British started the wars in the standard gentleman, structured and flashy red, neatly lined up troops, the South-African Boers adapted to the conditions, striking the British troops with flexibility and agility … organised and innovative chaos as some would say.

The agile manifesto and philosophy promotes innovation, frequent releases, features that are defined by and discussed with all stakeholders and humanoid collaboration. It creates an environment that is capable of reacting to changing requirements and most agile processes are suitable for projects with tight deadlines and changing scope.

Be rigid or agile … the choice is yours.

TFS | VSTS … Agile, TDD … ?

I reviewed the Visual Studio Team System 2010 CTP2 features back in November, see https://dotnet.org.za/willy/archive/2008/11/10/visual-studio-2010-ctp-2-3-7-agile-planning.aspx and https://dotnet.org.za/willy/archive/2008/11/21/visual-studio-2010-ctp-2-7-7-testing-amp-conclusion.aspx for some of the coverage. While I was relatively excited about the changes and the features introduced by CTP2, I am seeing stuff these days that is making me very excited about the agile working environment, the test-driven development features and the test-centric view on solutions and quality. The next CTP/BETA version of VSTS2010 will hopefully convince even the most critical reader, that we have a solution development environment that not only allows us to “morph” the tools into our environment, but that will make the agile processes a comprehensive reality … watch this space, because the next posts in this series will likely focus on these worlds in our existing universe q;-)

What we can and should be doing, is using the process, the tools and the guidance to go from a top heavy, fragile and last minute end-user testing environment, which are such a frequent and unfortunate occurrence in the trenches:

… to a bottom heavy proactive pre-user-acceptance testing environment:

Next … in this series …

To be decided … watch the space … ;-)

Comments

• Anonymous
  February 05, 2009
  This post is simply a collection of the various posts that made up the “ SDLC – Software Development

• Anonymous
  February 05, 2009
  This post is simply a collection of the various posts that made up the “ SDLC – Software Development

• Anonymous
  February 05, 2009
  Before I tick off another TechReady day, I will continue our SDLC discussion threads from SDLC – Software