Agile development methodology
Any successful business or organisation has to be passionate about getting the job done. That should go without saying you might think but in reality, for a whole variety of reasons, many organisations fail themselves and their customers by not being able to adequately complete what they’ve started.
At Brightec we’re no different from anyone else. We want to get the job done and done well but the pressures of multiple projects, deadlines, unforeseen complications etc. can threaten that goal.
To help us we’re big fans and users of the Agile development methodology.
Being agile with our clients
In our experience, we have found that the majority of our clients don’t use Agile methodology. This means that often trying to lever their processes and ways of working into line with ours can be a difficult exercise.
In an ideal world we would hand clients a small stack of books, a bottle of aspirin, some urls and ask them to go away and get clued up on Agile and our particular chosen Agile method so that they can work seamlessly with us. Of course, that’s not going to happen! Clients are paying us to do the work and that is exactly what they want, not to create more work for themselves.
The Agile Manifesto
Before we move on, let’s take a fresh (or maybe first time for you) look at the Agile Manifesto:
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
The third statement indicates that it is pretty important that our clients understand and can work with us in a productive, healthy and ‘agile’ manner.
To be able to create good working relationships one of the initial areas that is really important to get right is the use of User Stories.
From my experience, it would seem that in most real world examples of development agencies and clients working together, the client is usually unknowingly the product owner and that the internal Agile Coach/Scrum Master/Project Manager is having to fill in what the client cannot provide. In practice this means that the Agile Coach is often having to fulfil part of the product owner role as well as their role.
Anyone who understands a bit about Agile methods will tell you that this is a very unproductive, and potentially ill fated territory to find yourself in. This calls for an approach that can produce a seamless and efficient way of working.
In part two of this blog post we’ll look in a little more detail about introducing clients to User Stories and provide some developer friendly tips to help you along the way.