The project that I’m working on at the moment is pretty small. I’ve been given the freedom, or ability to introduce some of the concepts that I’ve been reading, and thinking about over the last year.
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!
We recently had a discussion about what the state of the development community at the moment. I’ve also had a blog post with a comment, where I stated is there a need for a BA!? This centred mainly around the make up of the team and who or what key skills you need in a team. As I’ve become accustomed to being just a developer over the past couple of years which has included either of the following: writing code, or supporting production code. Although this has been my primary role over the last couple of years I’ve come to realise – probably since discussing and studying Agile & XP especially that this is simply cannot be the case anymore.
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
I’ve been reading through the excellent “Specification by Example” in it’s early form from Manning. I’ve often struggled with the upstream practises of Agile. Recently I attended a work presentation surrounding capturing requirements and other work which BA’s undertake – it looked very “watefall-isk”! My concern was how to counter this discussion around sign off and the need for documentation.
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.
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!?
We had a really magnificent week away in Italy – this was all part of my dad’s rehabilation after he broke his ankle/leg in Switzerland on the Piz Trubinesca. You may know about this if you’ve chatted to me – if you don’t you can read the over media hyped version @ you can see it here!
We stayed in Livigno in the Picolo Tibet – which is run by Ercole (I think that’s how you spell it!) – he was a fellow patient in the St Moritz hospital that my dad spent 20 days in following the accident.
We spent the first part of the week skiing – it’s really good swishing down the slopes on the skis. I changed to snowboarding a couple of years back, but have since gone back to skiing. Due to a damaged board after a big gust in Scotland slightly damaged the board, and also I’ve got the gear for ski mountaineering now!
The second part of the week was spent ice climbing. The approaches where pretty awkward due to the depth of the snow – not having snow shoes really tells. Post holing as the “yanks” call it is really exhausting and time consuming when approaching routes. It seems to take a quarter of the time to get down after the route! It may well be time to invest in some snow shoes – the only problem is that they need to be easy to carry and collapsible – it seems that there is already a patent pending!
The first ice route was a WI 4+ it took about an hour and half to get to the bottom of the route the guide book time for the approach was half an hour! The Joy of Post Holing! It was really interesting climbing the top pitch the ice must have been half a metre thick sheet of ice. It kept thudding as you placed the axes and crampons. Quite interesting really – I didn’t put much protection because the ice wasn’t that thick!!! Both pitches where fantastic.
The second ice route was a WI 5 the guidebook says it is only a 90 metre route. It ended up being more like a 200 metre route. The gully was quite long to get to the main pitch which is a really nice sustained 5 pitch. The ice was just good enough to climb on the left – the centre was all rotten out – it had been in the sun too long and was really mushy!!! It was a really good route to do on the final day before travelling back to Zurich. Something to get the arms pumped!!!
A really good trip and a good place for my dad to continue his rehabilitation – to quote after the WI 4+ – “That’s the hardest thing I’ve been on since the accident!”.
Hopefully Scotland will stay/get in nick again so we can get up there for some more ice climbing in the coming weeks. Back to training & work for now!