Archive for December, 2010

Agile Projects like – “A Christmas Story”

December 18, 2010 Comments off

I have taken a few days off from work for Christmas and just watched “A Christmas Story” with my little one. It is not the first time I have watched this movie. What struck me this time was an analogy I could make – A decent family run by an able mother (Scrum Master) to see through a merry and happy Christmas (successful project delivery) in the face off all the madness around her. Ralphie asking for a BB gun (Developers insisting on shiny new IDEs and upgrades), Randy his brother just won’t eat (Operations not ready to deploy every time). The Old Man (Product Owner) who insists on a ridiculous leggy lamp in the window sill. With sheer shrewdness she could manage to destroy the lamp, ensured Randy eats at the table, puts her foot down when Ralphie blurbs the F word. Yet allows to be manipulated when the old man decides to get Ralphie the BB gun.

Organizations should not simply allow individuals who call themselves Scrum Masters to steer the projects, but should ensure they are good mothers to look after the family. Although it is true with any methodology, I think with Agile practices its paramount as they gather around her for breakfast (Daily Scrum). Families who do not sit down for breakfast or dinner sometimes also still seem to function normally. But on closer inspection you will notice many shortcomings in behaviours, virtues and personas.

From my own observations of many teams practicing agile are usually young and apt at adapting to changes quickly. Most despise the longer route of fully understanding the scope before starting the work. In other words generations that have grown up with “Instant Gratification” mentality and believe in talk is cheap and show me the goods. A good Scrum Master will make all the difference for the success or failure of such a team even though he/she is not the leader.

Categories: AGILE, ALM Tags:

Why we jumped on ALM/TFS 2010 bandwagon

December 3, 2010 2 comments

Back in May 2010, I sat down with my colleagues and CTO of the company to discuss Enterprise Strategy in particular – Teams using MS Stack at this company. The Product Development teams were using .NET 2.0/1.1, SQL Server 2005, consuming and exposing gateway web services. Applications ranged from Web Apps, Windows Services, Win Forms, Web Services and more. Methodologies, tooling and best practices were varied between different teams. TFS 2008 was solely used by Development teams for Work Item tracking and Source Control. Build Automation, Continuous Integration, SDLC Quality tracking and reporting were absent and sorely missed. Business Analysts, Testers, Project Managers, Architects all worked in isolation with their favourite choice of tools. However all of them collaborated using a common SharePoint site.

The Java teams were at the forefront when it came to tracking and monitoring software quality. Not that it couldn’t be done with the existing setup for MS stack, but with the new kid on the block VS 2010/TFS 2010 we decided to take a fresh look at it for our needs.

Where software was prescribed by so called “Enterprise Teams”, they soon got out-dated rather becoming roadblocks for natural evolution of applications and teams subscribing to enterprise services. Enterprise teams often lack budgets and suffer from gross negligence from business and project managers.

Our Leaders believed enabling smaller focussed teams and giving them space to innovate and deliver without losing, control, visibility and transparency was the way forward. This would empower lower ranks to make decisions freely with regards to tools, 3rd party software, Open Source etc. We all know how hard it usually is to start off with nothing. Teams and individuals easily lose sight and objectivity when they set off on a creative path. The only way we could solve this problem was to setup a Prescriptive Guidance and Reference Architecture for new teams and Greenfield projects to cross reference. That said it was only there if teams wanted to use it.

We came out of the meeting with a roadmap to embark on a Technology refresh for MS Teams starting with Team Foundation Server 2010 and Visual Studio 2010 Suite. This was an opportunity to setup a Best Practice Infrastructure, Platform, Tooling, Frameworks and more importantly Processes for teams.

What we liked about TFS 2010 and ALM back then

  • Team Project Collection and Team Projects for Business and Departmental alignment
  • Scalability, n-tier deployment, proxy caching for distributed teams
  • Team Web Access for Work Item Tracking which is quite powerful (Not all team member will need Team Explorer like in the past)
  • Project Portal (The fact that it can be organized to depict your company org chart, create cross functional teams etc.)
  • TFS 2010 ALM features such as Traceability of requirements for reporting
  • Out of the box Reports and Visualisation
  • Build Automation – Continuous Integration, Gated Check In, Work Item integration
  • Build Extensibility (Example: Build Number for Assembly versioning, PEX etc.)
  • Build Verification (MS Tests, Code Coverage, Architecture Validation etc.)
  • Test Management
  • Process Template Customization for your needs
  • Branching Visualizations
  • TFS 2010 Ease of Administration
  • Possibly win over Java guys with Team Explorer Everywhere integration with Eclipse IDE

and more…

In my next blog I will discuss how I went on setting up TFS 2010.

Categories: ALM Tags: