Recently,  I got the chance to work on a project which is using some of the principles from Agile Methodologies that are out there. The last time I mentioned we were using it,  I was watching Agile from an outsiders perspective. Now that I’m experiencing Agile for myself, I have to say its been quite interesting and indeed enjoyable.

So, heres the lowdown on how we’ve been doing it….

Agile: Our Story

 The first eight weeks consisted of 1 project leader and 3 developers (though this varied based on staff holidays and other immediate requirements). The idea was to create a new module which will be used to manage business processes, and to trial Agile Processes to assist in the development. The project is still ongoing, but has already started to bring tangible results, and indeed benefits to the team.

I won’t go into the technical details, save to say it involves c#, ASP. Net and C++ with SQL and Oracle Database back-end on an existing mature system.

Iteratively Speaking

There were several stages we went through,used a lot of new terms, and we were introduced a way of thinking which goes against traditional development processes.  Essentially the process used an iterative approach  which evolves over time. So much so, even the process itself has evolved to suit the needs of the team. I know this is not a new approach, but it is groundbreaking for the company I work for!

Work is carried out in iterations which usually last about 2 working weeks. what kind of processes typically happened during this follows.

Development Review: “Whats next?”

This process, usually  right at the start of an iteration allows the team to discuss, and come up with improvements and suggestions to the original “idea”and/or specification. This also allows the team to concentrate on a specific area of functionality, which can be driven by the needs of stake holders and the project  leader.

In this phase, which can take usually a day or 2, User Stories are generated. This is based on discussions over what is required as priority of this iteration. In our case included a already defined framework-specification which was to evolve over a period of time.  This doesn’t need to be the case, however e.g. “back of a cigarette packet” approach to the spec.

“A long time ago, in a galaxy far far away…”
User Stories are generally written on cards for ease of handling, they consist of 3 card types to make them up:

Storys
What a user of the system needs to do to achieve a goal. This equates to 1 functional unit, and usually comes in the form:

As an <Actor in the system>

I Want to <Do Something>

So that <the Actor can achieve some goal>

This is useful for stake holders to see what is required by a specific functional unit, and also guides the developer in the right direction to achieve the functional goal. This card also holds the total estimated units and the story number on it.

Tasks 

These are the estimated steps a developer needs to do. Generally the idea is to keep the units of work in the range of 0.5 – 3 units. The guideline is that if its too much more than this, then it s too big a task and needs to be split out. If its too small it should be incorporated into another task. These are designated with Story number.Task Number (e.g. 33.1) .

Acceptance Tests

An acceptance test is the test done by a project leader to verify that the work carried out in the tasks is complete.
This gave the steps needed to carry out the test and the expected outcome. there can be several acceptance tests, which when accepted by the project leader sign off the work. These are designated with letters i.e. Story Number.Test Letter (e.g. 33.B)

 Estimates: More than just a finger in the air…..

This development review allows a rough estimate to be placed.  Estimates are not done in actual time units rather an imaginary unit. (as chosen by the team – e.g. “bananas”).  The estimates are based on a collaborative  discussion between the members of the team. The idea is that a developer day is not always a full working day,  as developers can be distracted, disturbed, or can be pulled into other work. This is where the idea of Velocity comes in, to allow a gauge of speed of the development.

Velocity: Its Not Terminal…..

defined as how many imaginary units (e.g. “bananas” ) that a developer would do in an average day.

The Idea is that at the start you estimate the velocity as being low (e.g. 0.5 or 50%) to allow the team to get used to the project.  Then enough stories are put into to match the total units for the Iteration that have been estimated into the future work pile.  this is calculated as:

 Velocity * days in iteration * developers

As each iteration is completed, the velocity is increased a bit for the next, to get the velocity closer to 1. generally this doesn’t hit 1, but ideally (and as has happened on our project) the value gets to 0.7 when at full stretch.

Ouch! That hurts…

But what about things that cant be dealt with as a user story i hear you ask ? Typically the kind of things I’ve seen that fall into this category include:

• Clarification on how something is supposed to function, as it is not currently clear from discussions or from speccing it.
• Investigation of the use of a potential technology to aid in productivity and the user experience.
• Omissions (where a spec is involved) that need to be fleshed out.

this is where a Spike comes in.

 This is an item which cannot be answered straight away and needs further guidance. This allows someone to go and get an answer, or to investigate. This is also estimated, to allow it to be put into the development cycle.

The next phase is to actually to get on with it.

Do the work!

The developers take the discussed tasks and stories and develop. The self organising nature of  the team allows each member to decide which unit of work to do next. This means they can develop to their strengths, and can concentrate on areas of interest and or priority.

At the start of the iteration, User Stories are placed in one of the following phases:

1. Future  Work: This is work that will not be in the current iteration unless the current list of tasks have been completed.
2. Current Iteration: this is the work that is currently in the iteration to be done
3. Awaiting Sign-off: this is work completed, but not yet signed off.
4. Completed Work: Work that has been acceptance tested and signed off.

The rule is (generally) that a developer should only be working on one task in the current iteration. To keep track of progress a daily briefing meeting known as a Stand-up takes place to keep track of progress during the iteration

Standing room only

The team gets together daily to discuss essential development points since the previous meeting / stand-up. The idea is that standing up keeps the meeting to a minimum, because it’s generally uncomfortable to stand around too long. This keeps focus on important points.  Everyone is then aware of the progression of the team towards the end goal.

The typical things discussed are:

• What has been done since last meeting (each member)
• What is going to be done for next
• What problems and challenges encountered
• Status from external stakeholders on specific functional issues

This in our case meant that stand ups only last around a few minutes, unless there is a significant technical issue. These were usually handled as a separate technical discussion, between developers and not with the project leader unless it affected functionality.

Why Agile Works for us?

• Allows flexibility to be put into the design.
• The functions evolve as iterations pass and work is reviewed.
• A collaborative approach engages all relevant members of the team and the stakeholders.
• The work is in easily digestible units.
• Developers Feel ownership over their work.
• Better estimations of tme taken to complete the work.
• Early sign off of work, close to the development time.

So what do I think?

I’m sure there’s more that can be done to make this truly agile,  For example:

• Shorter release to market times.  In reality this might not have been possible on our product due to the nature of our customers and the maturity of the product. Also the module is some way off being available for RTM.
• Agile from the requirements phase. this means the design would then be driven directly by stakeholders

I’m sure I’ve only scratched the surface of the tools and methodologies available, but hopefully this gives an idea of how we used it and the benefits of using Agile Software Development.

The use agile methods can be controversial and sparks a great deal of debate. Needless to say I’ve become a proponent of this so far. I recommend that you research more into Agile and what this means, so that you can use the available tools to suit your needs.

Further Reading

This wikipedia page gives a good starting point for reading up on it. Any more links that you can find would also be helpful!

Firstly a whinge about ASP classic and yet another case of failing to keep pace.  Whilst I understand there are loads of classic asp pages out there (and these can be quite good), sometimes I wish things would move along with the times.  What I mean is no-one has really maintained the pile of cr*p pages I’ve been lumbered with (for the 2nd time!),  save where a functional change is required. No Housekeeping has ever been performed, so it has become more difficult to maintain. its totally frustrating!!

Heres why I hate the way this particular “web app” is structured:

1. Easy To Break: Changing something simple can break some other function that worked previously extremely easily, i.e. changing something like the format of data coming out can break other things.
2. Lack Of Modularity: i.e. it isn’t written in a way you can alter parts of it without affecting others significantly, and it is written in a scripting style.
3. Post-back Data Difficult to keep: Adding your own session handling is a labourious task, especially between post-backs.
4. it is a Security Nightmare for the DB: especially when considering the asp web in question has a place to put your own sql, leaving it open to SQL injection attacks galore! – I have raised this as a concern with management but the as the system is internal they do not think its a threat. (a bit naive I think on their part….as this would allow anyone, if you knew what you were doing, blatantly to hack our live database!)
5. Poorly Maintained: any functional changes to this code have been “Bodged” , wthout any proper thought. Unfortunately this breeds the “Bodge” Approach so that the application never really becomes clean.

I think I’ve been lumbered with the functional changes, because none of the other developers will or are inclined to touch it with a barge pole. The insulting part is that I’m in the process of becoming an MCPD Enterprise Applications in .Net 2.0 (with 3.5 to follow), having already qualified as Windows Developer. So I feel it’s totally wasting the skills I’ve picked up. As you can imagine this can be demoralising.  

Now before you go “stop moaning, Why don’t you Migrate it to .Net?” … I have also suggested and looked into it but because “it’s an internal application”, I’m told it doesn’t warrant a proper and much needed face-lift, so won’t be given the time.

Also, I reckon at first glance, the conversion would probably take around 4-6 man weeks and some testing besides to complete. Time unfortunately I don’t have spare (I do have a life!),

But i’m willing to look at ways the problems can be resolved incrementally.

So,  bearing in mind that this is an Internal Application not directly affecting the customer, but helps in internal functions i.e. support and development, the question is this; should it stay on classic ASP, because it works and has done for 10 years? Or does the application need to be migrated, to bring the benefits of having better support,  quicker to write new functionality, additional modularity and security features? 

Also, What arguments are there for migrating and against? And could there be a way to migrate slowly? For example could the classic ASP Pages hook off a serviced component written in .Net, rather than VB6 MTS ? Something to think about…

I’m going to attempt to tackle subjects, some of which I still need to get my head round. These will be coming up soon on this blog. Hopefully..and in no particular order, they may include:

• Agile Process pilot  -observations of what worked and what didn’t?
• Test Driven Development -  in simple terms
• C# feature of the week - Lambda functions (I think the c# feature of the week might actually turn into a regular post !)
• Design Pattern for Dummies (Another Idea for regular feature!)
• A brief overview of Windows Workflow Foundation

I’m using the blog to help me learn and understand, as well as help others. We’ll see how successful that is…..

DISCLAIMER

Firstly, I’d like to say that this article is not intended to to have a pop at individuals, rather the problems with processes which can give developers cause for frustration. They’re just my generalised opinions, and examples are here just to put my blog entry into context.

Cups and Lids… man I’m thirsty!

I’ve just read a recent, albeit small, Blog entry which highlighted the gap between stakeholders requirements and end products delivered within the software process. They summed it up in BASIC code….it was typically succinct but it made a valid point.

It got me thinking about a lunchtime conversation I had with a fellow colleague who summed the way the traditional lifecycle works for many places, and indeed my current workplace. So I thought I’d have a go at writing about it.

He analogised with a Drinks Cup from a Fast food Restaurant. To Protect the guilty, we’ll call it FFS or Fast Food Stores, or make up your own acronym of course!

I’m paraphrasing and adding artistic license, but here’s that fictional conversation between a PM and a Developer they created in that analogy, which I hope sums up the problem…

PM: Ok! For our Customers, FFS , We’d like a Soft Drinks Cup, as specified here… and we want it in X days….

< time passes…>
Dev: OK…Heres the Soft Drinks Cup you asked for…..

PM: The Cup is good but we just realised need a lid..

Dev: OK … thats wasn’t on was the original spec…. so you want a Lid? OK .. I’ll go make a lid

<more time passes…>

Dev: OK, So i’ve done the Lid.

PM: This isn’t the kind of lid we want.. it doesnt have button to signify if the contents are Diet..

Dev: but you asked for a lid, so I made a lid!

PM: but we want this too…oh and its missing a straw hole…. and we would like it in the time we allocated for Cup…oh… The deadline for getting the cups out to FFS was yesterday….

Dev: <bangs head against the wall several times>

All too often, this is the kind of the problem I’ve seen in my relatively short career in the industry, and not just in a Dilbert Cartoon.

The problem is, you might think as a developer you’ve met the requirements with the end product, but then the requirements that were set out originally:

• Did not cover important aspects which were core to the solution being realised.
• Didn’t consider adequately the impact on dependant or legacy systems.
• Changed mid flow due to stakeholder pressure.
• Didn’t cover what the customer needs correctly early on in the process.

The list above is probably not exhaustive, are just 4 of the kinds of things I’ve seen.

“It’s OK….We’ll make it up as we go along….”

in particular, I’ve had recent experience of the first and the second point.

For example, I’ve seen a spec document was so sparse, that in many cases one line of notes became the spec for a large chunk of functionality!

This meant that when the document was picked up by the dev team after initial development review and the development was started, It needed several pages of amendments in a section reserved for development decisions. This a section which should be kept to a minimum, for small decisions.

These additions were just to cover all the scenarios not fully thought out, and to allow the new system to work with existing legacy system’s functionality. It meant some radical changes, which had there been more awareness of these, less work may have been needed and more understanding of the requirement would have been gained.

This suggested to me, that the spec really needed a further review before proceeding, involving at least the lead developer of the team working. This is could have been done once the existing functionality and dependencies had been reviewed within the development environment.

Or it could be that the process of gathering requirements, speccing it up, and development may not be appropriate to the environment.

Now I’m aware that the problems I’ve seen in practice may be unavoidable, and that can sometimes be necessary to work in this way. But I’m sure there’s got to be something out there could reduce this, which is why I’m watching a recent development at work with some considerable interest…

Into Agile, The (Not So) new way of thinking….

One of the guys has managed to persuade the boss to allow them to trial Agile Development methodologies (e.g. Xtreme Programming) on one of the projects in the department, which is looking promising.

It appears to give a much more incremental approach to the development life cycle, with shorter times between reviews. It appears be far more collaborative in nature, that engages the participants and gives a better understanding of the requirement.

The Agile story so far…

The project has been running for a little while. There was some initial resistance to this approach, as there always is to new things within a well established and, in this case, traditionally minded software company. But, now most of those new to the approach seem to be keener on it as it’s being used. Its highlighted some of the weaknesses above, along with other things like underestimates in Timescales. Whether there is a more permanent change in the mindset of those involved remains to be seen, but I for one look forward to working with this in anger in the near future.

No doubt I’ll keep the blog posted on how its going…..

I’m going to use this blog to express opinions on some of the things I’ve picked up in the C# world, and to allow others to give their thoughts.

More to follow soon!