Thursday, March 31, 2011
To summarise – I have my own features for the functionality that I am going to implement. These have been written as acceptance criteria using SpecFlow – and the Given, When, Then syntax. Hopefully, this will ensure that the product that I develop delivers what the user wants (I can’t say what the user wants as this is a confidential product). I’ve found that my customer is extremely positive about using this, although we’ve probably not had as much face-to-face conversation as I would have liked. Maybe I should explain this… I’m convinced that some of the acceptance criteria would be better business aligned if we had a discussion rather than e-mail chain. Ironically, since I’m new, I’m probably a tad nervous or shy to be forcing workshops on people (people who know me might laugh at my shy reference!).
I’ve found the Given, When, Then extremely useful and forces me to think about what is important for the user. I’ve also used BDD/TDD for it as well – I’m more than confident that the design of the component I have written is a lot cleaner than I would have written a couple of years back. I’m pretty happy with the design and lack of duplication in the code. I’ve tried to be extremely hard on the refactoring – something I need to work on more and more.
The other thing I’ve started as of today is my own visual board. The reason for this is I’ve been struggling to focus on what to work on next. I’m interested in seeing how this works; I can already feel the benefit of having something visual forcing me to think what is next and get on with the work! Therefore, I know have:
I’ve had to get rid of what the cards actually say sorry, but they are just succinct pieces of work for this project. The pink items are blocks, or rather problems with the card – these need to be resolved before the card can be moved to “Done”.
I’m not going to apply Work In Progress limits yet, I’m not sure whether I need to apply this to the project – my estimate is that the work will take 10 days, so should fit in a single iteration!?
Really I should have a Continuous Integration environment for the project!
Wednesday, March 23, 2011
The main reason for this is due to the fact that XP & SCRUM just has a concept of a team – this includes everyone who is needed to deliver a product or rather something of value to the customer. The idea that when the time comes to deliver everyone needs to be able to help to deliver the product – this is mainly because there is not one person responsible for the delivery – the team is responsible. So this means that if there are tests to complete before the iteration completion date and no development work – then everyone needs to “muck in” to complete the tests.
This leads to teams of individuals with multiple skillsets – as an individual you might for one day have your developer “hat” on – the next day your “hat” is firmly in the “test” ring. Traditional role definitions are probably not well used here and are probably redundant. You are essentially just a team member who has more experience in development than testing, BUT you must be able to help with testing if the needs arise. If there is a bottle neck you must be able to relieve the pressure on the bottle neck – otherwise the “team” will not deliver.
This ability to learn different skills leads me to another important asset of any team member – you must be willing to learn. I think Agile especially encourages this, since everything is an experiment? I was listening to a Podcast with Lisa Crispin and a couple of her final thoughts centred on the need to learn and willingness to learn. It must have struck a chord - because I was skiing at the time! I believe these are key skills for anybody working within in an Agile team.
For me this leads to a couple of core things to look for in team members:
- Willingness to learn
- Ability to adapt to the needs of the team
Monday, March 21, 2011
I’m so glad that I was able to get hold of “Specification by Example” – it’s given me plenty of ideas of how to promote a different way to work. The benefit of living documentation has got to be a good starting/selling point!?
This lead me to ponder what the role of a BA was within an agile/lean organisation. It seems to have been an area that has been left behind over the years. This is primarily due to the fact that most of the original Agile Manifesto signatories where people from the software development field.
I’ve often wondered whether User Stories is all Business Analysts should do; in fact do you need Business Analysts?
Specification by Example answers a lot of questions around capturing requirements in the early phases of an agile/lean project. I’ve tried to map out how I see the process within our organisation – I’m not sure whether it’s what is intended but it’s something that I want to try out in the future:
I will write more about the book, but my first impressions are that I would recommend this to anybody who is developing software, it is extremely informative and well written.
Wednesday, March 16, 2011
Over the last couple of years the term strategic and tactical has become more apparent to me, this is probably because people have talked about the need for strategic software solutions against the need for tactical software solutions.
I’ve been pondering what this actually means to me! What impact does a tactical solution have on the end user? What does a strategic solution have on an end user? My gut feeling is that the answer would be nothing.
So let’s flip the question around, because I believe the term is coined by developers/management. It may even be an excuse for not doing certain practises. A tactical solution is a quick fix; with very light weight Project Management around it, there may not be time to do any tests and the whole attitude is doing whatever it takes to deliver with the least amount of effort. A strategic solution has PM’s, BA’s and Project Management around the solution. This makes it strategic because there is more governance. We’d prefer to take our time on this project because of its strategic importance.
The definition for strategy is:
- “A word of military origin refers to plan of action designed to achieve a particular goal.” or;
- “Highly important to an intended objective”
The definition for tactical is:
- “Less of a long-term significance than strategic operations”
From briefly wiki-ing and searching on the web, the terms “strategic” & “tactical” seem to have their history in the military. Strange that software development has adopted these words, my view is that there meaning has been modified incorrectly for software development.
If you were to apply these words to software development, maybe they should have a different meaning to what I’ve seen. So here is my 50p’s worth. The strategy is where the overall “architecture” of the company is going – i.e. we want everything to be SOA. The actual implementation – writing of code is tactical – i.e. we will implement this through a RESTFul service using WCF.
Both the development of the application and the overall “architecture” of the system should be aimed to align closely with what the customer actually wants.
The customer probably doesn’t care what the strategy is – they probably only care what the tactical delivery is!?