The Naked Agilist conference podcast is now available at http://www.nakedagilists.com/jan-08 complete with my presentation on TDD on Data Management projects.
While I am on the subject, I was very pleased that Brian Marick took the time to review my previous post which was in response to his talk and advertise it on his blog. Thanks Brian!
Tuesday, January 22, 2008
wevouchfor.org - A Community Approach To Certification
Certification is a controversial issue in the Agile community at the moment. Some people think its a great idea that is necessary for Agile to grow, while others argue it makes it harder to separate truly talented contributors from the rest of the pack.
Laurent Bossavit presented an alternative (complementary?) approach on January's Naked Agilists mini-conference which he and Brian Marick have cooked up with a little help from their friends.
It's a website called wevouchfor.org which borrows a few ideas from social networking sites to allow software people to publicly "certify" each other based on hard evidence of a job well done. For example, Clarke Ching certified Laurent as follows..
I think this is a wonderful approach, and very well executed too. One of Agile's strengths is its strong focus on team decision making as the only way to get reliably solid decisions on matters which affect the team's ability to deliver - your boss can only act on what he or she can see, but you can never pull the wool over your peers' eyes! This site is typical of that ethos and if it is widely supported it has the potential provide a very reliable indicator of an individual's true credentials. This would be as good for the individual as it would for his or her colleagues or potential employers.
The first iteration is now live and Laurent promises more features are in the pipeline. The registration and certification process is extremely quick and easy so I hope you can find a moment to sign up and give some credit to people who have helped you in the past.
Laurent Bossavit presented an alternative (complementary?) approach on January's Naked Agilists mini-conference which he and Brian Marick have cooked up with a little help from their friends.
It's a website called wevouchfor.org which borrows a few ideas from social networking sites to allow software people to publicly "certify" each other based on hard evidence of a job well done. For example, Clarke Ching certified Laurent as follows..
Clarke Ching certifies that Laurent Bossavit is qualified as a master, capable of innovating in the skill agile adoption, based on this evidence:
I spoke with Laurent on the nakeagilists podcast and I was very impressed with his thinking, intentions and attitude: putting his spare time into producing this website wevouchfor.org (along with Brian)which benefits our community. The website speaks for itself and for both Laruent and Brian's skills and motivations. Well done!
I think this is a wonderful approach, and very well executed too. One of Agile's strengths is its strong focus on team decision making as the only way to get reliably solid decisions on matters which affect the team's ability to deliver - your boss can only act on what he or she can see, but you can never pull the wool over your peers' eyes! This site is typical of that ethos and if it is widely supported it has the potential provide a very reliable indicator of an individual's true credentials. This would be as good for the individual as it would for his or her colleagues or potential employers.
The first iteration is now live and Laurent promises more features are in the pipeline. The registration and certification process is extremely quick and easy so I hope you can find a moment to sign up and give some credit to people who have helped you in the past.
Sunday, January 20, 2008
Sentient Life Found Beyond Objects
Brian Marick made a bold statement in his presentation on last night's Naked Agilists Skype conference. The podcast will be available soon but, put simply, his point was this.
With reference to Moore's technology adoption life cycle, Agile methodologies have crossed the chasm between visionaries and pragmatists only to find that, in his opinion, there are not many true pragmatists out there and the only option is to skip straight to the conservatives. He feels that the original visionaries are now spread very thinly across the world consulting with Conservative companies and the development of Agile would be better served if they were to retreat back to Visionary companies and work together on real projects creating new innovations.
Well done to Brian for sticking his neck out and making such a bold statement. As one of the original signatories on the Agile Manifesto and a consistent contributor and leader in the community, he is well qualified to comment on how Agile is being applied across the industry. Clearly, he has seen some things that have disturbed him greatly and has been moved to comment this strongly.
He is also the first to admit (listen to the podcast) that he would love to discuss this much further so I would like to offer an opinion on a factor he might not have considered...
The Agile community is too heavily skewed towards Object Oriented languages and people believe it only works with Object Oriented languages.
Back in the day, the patterns community, who were the thought leaders in the objects community, met up with the leaders in the methodology community and created what we now know as Agile (OK, so I skipped a few steps along the way, but please run with it). Naturally, the technical practices on OO projects continued to evolve and the people involved wrote the definitive works on refactoring, TDD and Agile design.
Let's be absolutely clear on something. I don't want to, even slightly, cast any doubt on the excellence and relevance of these books and I am certainly not trying to belittle the efforts or success of the people who wrote or have read them. But there is a problem. No one is writing technical books about anything other then OO technologies.
So why is this important?
Because Big Companies Are Conservative
The converse is not true (there are small conservative companies too), but in order for Agile to become truly mainstream it needs to establish itself in IT departments at multinationals like telcos, banks, media companies, major retailers and energy suppliers (the list is endless!)
Big companies like these employ legions of programmers, designers, architects, testers, managers and support staff who don't know about objects, don't do UML and think Ruby is a sort of red diamond. It's not a problem though. They don't need to know about objects because they have built their careers with languages and environments like Ab Initio, COBOL, Siebel, SAP, SAS, PeopleSoft, Business Objects, Brio and Teradata to name but a very few.
These technologies are the heart and lungs of the company and the latest J2EE or Rails website would be pretty useless without them quietly churning away in the background supporting the business's ability to deliver. Of course, we know that nothing really churns away quietly, so we need people to look after them and projects to update them and add new functions when the business environment changes - just like anything else.
It's not glamorous or sexy, but it's still very challenging and often cutting-edge work which is subject to exactly the same project pressures as the latest marketing initiative.
Unfortunately, when the IT director at a multinational looks at Agile, his or her first reaction is not that of one of Moore's Visionaries who would wonder "will this help me achieve 10X productivity gains". It's more likely to be "how does this affect my ability to keep the lights on". And that's the right place to focus - failure to do so would be reckless, career ending and maybe even illegal (governments tend to take a dim view of telecoms operators that cannot reliably provide, for example, 999 emergency services).
So what can we do?
Scrum, Crystal and DSDM have shown us how to work iteratively, Lean has taught managers how to think about software development, but a team cannot be truly Agile without the Extreme Programming technical practices that allow it to truly embrace change. It is essential that we can provide documented proof and guidance on how to apply the technical practices across a wide range of modern and legacy technologies rather than just the new era of OO toys.
The adoption pattern is there to see from the OO world. We need expert visionaries from untried technical domains to stand forward, say "YES! This is possible using Product X", and then go and make it happen. We need blogs, articles, conference presentations, training courses and, ultimately, books to guide Agile virgins through the technical practices using a range of technologies. We need to show business software vendors that they can differentiate themselves by supporting their clients Agile development needs.
That's what I am doing, but I can only work with what I know so I will end with a rallying call to the next generation of visionaries:
If you are breaking ground in non OO environments - especially business software - please write about it! There has never been a better time to make a real difference and maybe a name for yourself too.
With reference to Moore's technology adoption life cycle, Agile methodologies have crossed the chasm between visionaries and pragmatists only to find that, in his opinion, there are not many true pragmatists out there and the only option is to skip straight to the conservatives. He feels that the original visionaries are now spread very thinly across the world consulting with Conservative companies and the development of Agile would be better served if they were to retreat back to Visionary companies and work together on real projects creating new innovations.
Well done to Brian for sticking his neck out and making such a bold statement. As one of the original signatories on the Agile Manifesto and a consistent contributor and leader in the community, he is well qualified to comment on how Agile is being applied across the industry. Clearly, he has seen some things that have disturbed him greatly and has been moved to comment this strongly.
He is also the first to admit (listen to the podcast) that he would love to discuss this much further so I would like to offer an opinion on a factor he might not have considered...
The Agile community is too heavily skewed towards Object Oriented languages and people believe it only works with Object Oriented languages.
Back in the day, the patterns community, who were the thought leaders in the objects community, met up with the leaders in the methodology community and created what we now know as Agile (OK, so I skipped a few steps along the way, but please run with it). Naturally, the technical practices on OO projects continued to evolve and the people involved wrote the definitive works on refactoring, TDD and Agile design.
Let's be absolutely clear on something. I don't want to, even slightly, cast any doubt on the excellence and relevance of these books and I am certainly not trying to belittle the efforts or success of the people who wrote or have read them. But there is a problem. No one is writing technical books about anything other then OO technologies.
So why is this important?
Because Big Companies Are Conservative
The converse is not true (there are small conservative companies too), but in order for Agile to become truly mainstream it needs to establish itself in IT departments at multinationals like telcos, banks, media companies, major retailers and energy suppliers (the list is endless!)
Big companies like these employ legions of programmers, designers, architects, testers, managers and support staff who don't know about objects, don't do UML and think Ruby is a sort of red diamond. It's not a problem though. They don't need to know about objects because they have built their careers with languages and environments like Ab Initio, COBOL, Siebel, SAP, SAS, PeopleSoft, Business Objects, Brio and Teradata to name but a very few.
These technologies are the heart and lungs of the company and the latest J2EE or Rails website would be pretty useless without them quietly churning away in the background supporting the business's ability to deliver. Of course, we know that nothing really churns away quietly, so we need people to look after them and projects to update them and add new functions when the business environment changes - just like anything else.
It's not glamorous or sexy, but it's still very challenging and often cutting-edge work which is subject to exactly the same project pressures as the latest marketing initiative.
Unfortunately, when the IT director at a multinational looks at Agile, his or her first reaction is not that of one of Moore's Visionaries who would wonder "will this help me achieve 10X productivity gains". It's more likely to be "how does this affect my ability to keep the lights on". And that's the right place to focus - failure to do so would be reckless, career ending and maybe even illegal (governments tend to take a dim view of telecoms operators that cannot reliably provide, for example, 999 emergency services).
So what can we do?
Scrum, Crystal and DSDM have shown us how to work iteratively, Lean has taught managers how to think about software development, but a team cannot be truly Agile without the Extreme Programming technical practices that allow it to truly embrace change. It is essential that we can provide documented proof and guidance on how to apply the technical practices across a wide range of modern and legacy technologies rather than just the new era of OO toys.
The adoption pattern is there to see from the OO world. We need expert visionaries from untried technical domains to stand forward, say "YES! This is possible using Product X", and then go and make it happen. We need blogs, articles, conference presentations, training courses and, ultimately, books to guide Agile virgins through the technical practices using a range of technologies. We need to show business software vendors that they can differentiate themselves by supporting their clients Agile development needs.
That's what I am doing, but I can only work with what I know so I will end with a rallying call to the next generation of visionaries:
If you are breaking ground in non OO environments - especially business software - please write about it! There has never been a better time to make a real difference and maybe a name for yourself too.
Wednesday, January 16, 2008
Naked Agilists: 19 Jan 2008
I am giving a talk at the Naked Agilists skypecast on the 19th to talk about TDD on data management projects. My synopsis is as follows...
We are having a few problems getting Skypecast to work at the moment, so please join the list to find out the new arrangements as they become clearer.
The conventional wisdom in the design and testing of Object Oriented systems is to isolate application functionality from the underlying data model. How then, do we adopt Test Driven Development for projects where the goal is to transform the raw data and Object Oriented languages are not used? This presentation introduces the TDD approach I have successfully pioneered on my own data management projects and FIT4Data - the FIT-based testing framework I wrote for the purpose.
We are having a few problems getting Skypecast to work at the moment, so please join the list to find out the new arrangements as they become clearer.
Yahoo Agile Data Management Group
I have started an Agile Data Management group on Yahoo. It's at http://tech.groups.yahoo.com/group/agile-datamgmt/
This group is for the discussion of all aspects of applying Agile principles and practices to data management projects. It is intended to compliment the existing Agile Databases group and the key distinction between them is that this group covers situations where working with raw data is the primary focus of the project or application. For example, data warehousing, data migration, data cleansing and operational data transformations.
The focus of the group is wide ranging covering both technical and management topics and is open to everyone from novices to experienced practitioners.
This group is for the discussion of all aspects of applying Agile principles and practices to data management projects. It is intended to compliment the existing Agile Databases group and the key distinction between them is that this group covers situations where working with raw data is the primary focus of the project or application. For example, data warehousing, data migration, data cleansing and operational data transformations.
The focus of the group is wide ranging covering both technical and management topics and is open to everyone from novices to experienced practitioners.
Friday, January 4, 2008
Hello and Welcome
Well 2008 is upon us and it's New Year's resolution time. Mine is to start a professional blog to record and make public the thoughts, musings, discoveries and general tribulations of my working life. I might get into a few other bits and bobs too - but let's see how things go.
So what has led me to the (possibly rash) decision to take some time out of my busy schedule to maintain a blog?
A bit of background
I am a professional software developer based in the UK who specialises in data management using Ab Initio. I studied computing at university for the simple reason that I liked it and was reasonably good at it and I joined the workplace as a graduate developer back in 2000 full of bright eyed enthusiasm for writing great solutions. Like many developers progressing through the ranks from graduate to seniority I became increasingly disillusioned with the reality of the politics and methods used in the real world. It was especially disheartening to find that developers are almost at the bottom of the food chain in most companies (apart from the testers who, as bearers of bad news, are often treated even worse). We were the people who were creating the system so surely everyone involved would be judged on the success of that system from initial release to eventual decommissioning. Why, therefore, was everyone not not lining up to support us?
There had to be a better way! I just couldn't find it that's all.
It's not that everything was bad, of course. I have worked on many projects, some were great, others were not and most fell somewhere in the middle. On every one of them, I worked beside some fantastic, heroic people who made real difference. Sometimes they were even recognised for it! However, my enthusiasm for the job was seriously waning. I had retained enough of a spark for technology to resist the gravitational pull towards management but I was seriously considering leaving the IT industry to do something completely different.
Thankfully, everything changed when I was introduced to Lean Agile by the inspirational Nancy Van Schooenderwoert. She showed me there is a better way and it's even better than I could have ever have imagined. The Agile principles and practices made immediate sense to me especially the way Lean thinking and Agile methods put the team at the centre of everything with spectacular improvements on quality, productivity and team satisfaction - my suspicions were confirmed!
That's all very interesting Adrian, but why the blog?
The problem we face as data management professionals is that the vast majority of the Agile thinking and literature is focused on developing UI based applications like websites and gadgets using Object Oriented technologies so it's not immediately apparent how to apply agile to data management projects like data warehouses. The purpose of this blog is to publish the findings of my work with Nancy and my company M2Consortium on how to bridge this knowledge gap and explore new ideas as they come up.
Over the past year or so I have been greatly inspired by Jeff Attwood's blog Coding Horror. It has nothing to do with data management or Ab Initio and only makes occasional references to Agile but many of his posts are stimulating I like the way his enthusiasm for what he does comes across very clearly. If I can be even a quarter as good as Jeff I will be very pleased but I am up for a challenge and on his advice I have decided to pick a schedule I can realistically expect to meet. So, drum roll please...
I will post at least once every three weeks.
... cue muted applause...
OK, so it's not very often and I will try and do better, but I have no idea how this is going to work out so I would rather commit to something I can definitely manage than set the bar too high. Please watch this space and Happy New Year!
So what has led me to the (possibly rash) decision to take some time out of my busy schedule to maintain a blog?
A bit of background
I am a professional software developer based in the UK who specialises in data management using Ab Initio. I studied computing at university for the simple reason that I liked it and was reasonably good at it and I joined the workplace as a graduate developer back in 2000 full of bright eyed enthusiasm for writing great solutions. Like many developers progressing through the ranks from graduate to seniority I became increasingly disillusioned with the reality of the politics and methods used in the real world. It was especially disheartening to find that developers are almost at the bottom of the food chain in most companies (apart from the testers who, as bearers of bad news, are often treated even worse). We were the people who were creating the system so surely everyone involved would be judged on the success of that system from initial release to eventual decommissioning. Why, therefore, was everyone not not lining up to support us?
There had to be a better way! I just couldn't find it that's all.
It's not that everything was bad, of course. I have worked on many projects, some were great, others were not and most fell somewhere in the middle. On every one of them, I worked beside some fantastic, heroic people who made real difference. Sometimes they were even recognised for it! However, my enthusiasm for the job was seriously waning. I had retained enough of a spark for technology to resist the gravitational pull towards management but I was seriously considering leaving the IT industry to do something completely different.
Thankfully, everything changed when I was introduced to Lean Agile by the inspirational Nancy Van Schooenderwoert. She showed me there is a better way and it's even better than I could have ever have imagined. The Agile principles and practices made immediate sense to me especially the way Lean thinking and Agile methods put the team at the centre of everything with spectacular improvements on quality, productivity and team satisfaction - my suspicions were confirmed!
That's all very interesting Adrian, but why the blog?
The problem we face as data management professionals is that the vast majority of the Agile thinking and literature is focused on developing UI based applications like websites and gadgets using Object Oriented technologies so it's not immediately apparent how to apply agile to data management projects like data warehouses. The purpose of this blog is to publish the findings of my work with Nancy and my company M2Consortium on how to bridge this knowledge gap and explore new ideas as they come up.
Over the past year or so I have been greatly inspired by Jeff Attwood's blog Coding Horror. It has nothing to do with data management or Ab Initio and only makes occasional references to Agile but many of his posts are stimulating I like the way his enthusiasm for what he does comes across very clearly. If I can be even a quarter as good as Jeff I will be very pleased but I am up for a challenge and on his advice I have decided to pick a schedule I can realistically expect to meet. So, drum roll please...
I will post at least once every three weeks.
... cue muted applause...
OK, so it's not very often and I will try and do better, but I have no idea how this is going to work out so I would rather commit to something I can definitely manage than set the bar too high. Please watch this space and Happy New Year!
Subscribe to:
Posts (Atom)