Can the wrong tools stop you being agile?

One of the Agile manifesto's preferences is for people and collaboration over tools and processes.  For example, having a 2 minute face-to-face conversation is preferred over sending an email.  This is an admirable foundation for the philosophy, but what happens if the environment, technology or tools you must use on a project get in the way of collaborating and being agile?

My current project is customizing a Siebel installation as the organization's CRM solution, and so we have to deal with Siebel's technology.  I have to admit i have never worked with this technology stack before, and so I am relying on the solution architect, team leaders etc for their views on this, which I respect.

The issue comes when it is time to deliver new code to the test environment. Development and unit testing happens in a separate dev environment, then released to the SIT testing environment for system testing. This is the first step in the delivery chain, so each release to SIT becomes part of a collated release to UAT, etc.

Releases can take the form of an SRF, a Repository update, Static data, Workflows, etc.  The problem is that these releases are time consuming and have to be made under a release management process, which involves two other teams (release management, environments) and creating interim documentation (release notes). Because of this, releases cannot be ad-hoc or flexible, and have to be scheduled. This was exacerbated by the release and environment teams being unwilling to perform more than 2 releases per week.

Unfortunately, the team has morphed this into the need for a release plan - scheduling to finish user stories for a certain release date - and so a lot of planning day is consumed by trying to fit user stories into the release schedule so that a tester has enough time to test it.  And what does that look like - mini waterfalls in a sprint!

This has some obvious (to me) drawbacks, in that a missed release date could delay a user story by two days! even for a 2 minute bug fix, so quick turns around times to improve through feedback were non-existent.

In terms of Scrum, it meant that the team were always focused on delivering to the release plan, rather than having the flexibility to deliver when ready (they were even admonished for delivering a story early, as it was not in the release plan!).  Also, since no work could be delivered after the last release, there was a premature end to the sprint which increased the likely hood of stories 'carrying over' to the next sprint, against agile principles. It was estimated that around 10% of capacity was wasted because of waiting time or lost time.

Finally, I also had the impression that some of the team, including the release manager, were deliberately using this as an excuse not to be agile as they didn't want to change.

Unfortunately, in dealing with this situation, I had to wait until the release manager was replaced to get any movement in this area.  When that happened, I immediately went to daily releases - which although not the ideal, helped a lot. 

It meant that I could downplay the importance of the release schedule, and so get back to a more flexible approach to taking on and delivering work, and it meant that we could have releases up to the end of the sprint, so using all available capacity.  I would have preferred to have dropped the idea of a release schedule completely, but this bit of team culture was ingrained pretty deep and the teams elected to keep it.  Our new release manager also helped a lot, as her whole approach was one of helping to deliver, and being flexible but controlled.

The ideal situation of continuous integration is not always possible: The limitations of older technologies, together with old-style ways of working, can severely impede a team from realizing its full agile potential.  But by approximating to CI, and having the will to be flexible, can improve the situation - we were able to reclaim the 10% capacity, and greatly improve the pressure on testing.

Team Culture: difficult to change

I find that one of the most difficult aspects of change a team may have to undergo is one of culture.

Changing the membership, meeting times, workload, locations etc of a team, its relatively easy to get buy-in, as long as you give good reasons and gain consensus.  But there are other aspects of moving a team to an agile way of working that call for much deeper and controversial solutions.

Many teams (including my current ones) on their first agile project still have old-style tendencies that hinder best performance and becoming fully agile.  For example, even within the same team, there can be an "Us and Them" attitude between developers and testers, and at times with POs also.  While these are obvious divisions, this is in the context of traditional management methods which set up these divisions for their own convenience.  But this can be a continuous source or argument, shirking of responsibility and, frankly, arse-covering which all detract from productivity.

To be fair to my teams, the culture of the project did not start with Agile - in the beginning it was a traditional, quasi-waterfall project with design, 3x development and test teams, all with team leaders and managers in the usual hierarchy.  This has been a difficult culture to change: we still need the people who are the team leaders, even if their role has diminished significantly, but this preserves the divisions between them.

One of the central tenets of Agile is its focus on teams, teamwork, and working together towards a goal, and so members need the space to be flexible and adventurous in working outside their comfort zone role when needed.


One example here is when a team realized they didn't have enough test resource to test all the stories developed by the developers.  When given this problem, the team mulled over the suggestion of developers testing each others code, with a caveat that a tester would still do final testing.  Most of the developers were ready to do this, but when pushed, the testers - and test manager -  somehow managed to find enough time to do the testing after all (by working weekends!).

Another example is within the test team themselves - when none of the Siebel tester's in a team would test a Data migration story because "they don't do that"

A true cross-functional team would allow this to happen - in a controlled and visible way so as to maintain quality - but also to enhance productivity without using more hours.  But I felt that while the old divisions remain, Agile's goal of super-productivity can only be approximated.

To help solve these problems, or to try to break the divisions can call for difficult decisions, such as the obvious one of removing the team leaders - but this is often not possible or popular!  Better to engender a new culture of sharing, team-ownership and safety to allow team members to be adventurous.  This could be done through workshops where testers show developers how they test, and vice-versa, and inviting testers to develop some stories in line with their ability (Testers are often good developers too).  Not only does this encourage all the good things of agile teams, but supplies a form of training and teamwork not possible in traditional methods.   

The Team in The Programme

Sept 2010:

As I join The Programme, there was still 18 months left to go - 15 for development and 3 for the last rollout.  The team structure is as follows:

• 3 teams of cross skilled developers, testers, and BAs - team sizes about 10 in each
• Most developers are from the same consultancy, they are a mix of Siebel, OBI and Data migration developers - each discipline has a team leader. There are around 14 devs in London, 3 in Mumbai
• All testers are independent contractors, lead by a test team lead (who doesn't test)
• BAs are mostly contractors, some permanent employees too.

There are around 10 BAs, lead by a team leader.  So three BAs in each team acting as proxy product owners. Interstingly, the "BA team" is using Scrum to organize their work, so they have a separate stand-up each day to synchronize on the analysis of the problem domain.  While this is outside of my scope, I will find out more about this - Scrum applied to analysis.

Other people on the programme: Solution Architect, Programme Manager, Director, Infrastructure team, Support team.

Parameters of content

In starting to write this blog., I first asked permission from my department managers, line managers and programme managers for the kind of content that I should conform to.  Mostly they were very open to the idea, and were happy for me to do this - but in an anonymized way - so names are changed to protect the innocent.

I dont think this matters, and will have little impact on content, as I intend only to document, explain and review the decisions of the programme in terms of Agile Methodology

Start of a new blog

This is the first entry in this blog, so i should eplain what I am doing here.  This space is for me to note, remember and share the experiences, activities and lessons learned that I encounter in my role as a Scrum Master and Agile Evangelist.

I will try to bring this up to date with my experiences so far from the past 3 years, but also add to this with my current role.

While this is predominanlty for my own benefit, please feel free to review and add your own comments and suggestions, and I will try to answer any questions too.