Wednesday, March 17. 2010Fitnium 2.0 and SLiM
I now have a version of Fitnium working with SLiM, version 2.0 to be release shortly will include support for the existing Fitnesse DoFixture plus support for the SLiM Script Table
You will be able to continue using your existing scripts with no change, but also start developing in SLiM Wednesday, March 10. 2010Agile & Diving
I've recently started a new Agile coaching gig in the Telco space. The team are already into the development cycle but had been struggling with scope, quality and communication, hence the call from the programme manager one day
They already have a system in production and have ongoing support requests, plus a decent sized team 16+ people actively seeking work each day, there is not the option do a drains up coaching exercise and get everyone trained in the basics before we start cutting code, testing and delivering, there is a business to run. The approach I've taken reminds me of how you learn to dive. Start simple, head under the water and breath, then introduce the concepts one by one, mask clearing, BCD ( buoyancy control ), proper finning etc piece by piece, but only after the team demonstrate that they have mastered the current activity. Basically I am brain training them, getting them to accept and adopt a specific practice to the point where it becomes second nature. Just like with diving you don't progress to open water until all the safety procedures are pretty much second nature. When it goes wrong you don't think, you just act and therefore you don't drown. We started with planning, poker and standups and did not change anything else about their current process. Just these 3 aspects got the teams talking more, got developers and testers talking to analysts and demonstrating finished functionality in small easily understandable and therefore testable chunks. People saw the changes added value and actively started seeking more advanced Agile concepts, automated build and testing, mock objects etc, but always under the control of the coach at first to make sure they were doing it right. This reminded me of when I did my first pool session, I was taught the basics, the instructor making sure I did them all correct and then let me play in the pool, but never so far away as he couldn't keep an eye on me and correct anything that he saw was wrong. I practiced full mask clearing ( only been taught partial mask clearance ) and I practiced buoyancy control through breathing in and out ( we'd only be shown how to use the BCD ). This analogy reminds me that the concepts of agile are not new, just best practice and easily learnt and if taught in small easily digestible parts allows the student to progress to new areas at their own speed. Tuesday, November 18. 2008
Jakob Nielsen on Agile Development ... Posted by Keith Sterling
at
12:09
Comments (0) Trackbacks (0) Jakob Nielsen on Agile Development and Usability
Jakob Nielsen writes about Agile Development and Usability and how agile can pose new threats to to user experience quality.
However he does go on to show in the article how Agile can be used in enhance user experience by not approaching agile in a narrow fashion, but open it up to embrace usability testing and end user involvement in design. Monday, November 17. 2008The Decline and Fall of Agile
James Shore has written an excellent article The Decline and Fall of Agile where he points out that Agile projects are failing because too many of them are only adopting parts of the agile principles. Lots of projects are doing short iterations and increasing planning, but too few are doing more of the esoteric or softer practices correctly.
This follows on from my previous post that too many people are being churned out of CSM courses with effectively 2 days Agile training and then trying to apply this skill on major projects. Therefore anything not taught on the course is not applied because it was not on the course, unfortunately good development leads are not created then are forged out of years and years working on successful and not so successful projects. Just as their software grows, as does their understanding of what it takes to build great software. I know so many good agile dev leads that either don't have CSM or have because their company paid for it, but never needed to go on it in the first place. They are good because they have always been good and will continue to be pragmatic and agile in their adoption of all that is good in agile itself Sunday, November 9. 2008
Scrum Ceritification - Atlast it ... Posted by Keith Sterling
in Scrum at
09:47
Comments (0) Trackbacks (0) Scrum Ceritification - Atlast it might mean somethingInfoQ: have a interesting discussion about the value of the Certified Scrum Master certification. I've always been trouble by the value of CSM certification, not because of the course per say, but the fact everyone who turns up for the course is awarded it, and the the certification is being used by people to suggest that are experienced at running Scrum projects. However the big players in Scrum are starting to take notice and are discussing the need for a test at the end which would ensure that every candidate has the required level of understanding of Scrum before they can use the CSM certification Sunday, November 9. 2008
Agile development: It isn't just for ... Posted by Keith Sterling
in Agile at
09:15
Comments (0) Trackbacks (0) Agile development: It isn't just for small projects
Scott Ambler and Damon Poole discuss how IBM scales Agile across large teams ( sometimes in excess of 500 people ), in an article Agile development: It isn't just for small projects
While a brief article it does touch on one or two of the really key problems facing agile scaling; how to size and split teams into management units. As Ambler says "The architecture should be a system of subsystems." and therefore according to Ambler "the structure of the teams should be aligned with the architecture, and ideally the sub-team members should be co-located." I have to admit that I always saw greater perceived value in creating teams that attack vertical slices through the architecture, ultimately these teams deliver end to end stories, and this worked extremely well on a major project I did for AOL. However at one of my current clients, this is just not feasible at this stage, the political makeup of the organisation and the inherent compartmentalization of existing teams, mean that its has been a major ( and ultimately impossible ) struggle to get a manager ( who once controlled his whole team ) to seed various functional teams with one or 2 of his assigned developers. We have therefore grown into a suite of teams split by architecture. Time will tell if this will actually work Thursday, November 6. 2008Selenium API Spreadsheet
While I think Selenium is a great tool, the documentation can be a little difficult to work out the specific command. As part of a training course I have been developing, I have created the following spreadsheet of Selenium IDE API calls which you might find useful
http://spreadsheets.google.com/ccc?key=pq3bDQaoQ3jphqQfHrfKRYw Shared on Google docs Tuesday, November 4. 2008In Search of Stupidity - A Review
I love this book, In Search of Stupidity by Merril R Chapman
If you grew up with computer companies in the 80's, and remember MS-DOS, Lotus 1-2-3, Wordstar, dBase, Ashton Tate, or just want to know why Microsoft got big and Borland suck then this is the book for you. The author's personal experience on WordStar is used to dissect many other of the software industries great marketing fowl-ups. If you are involved in writing or producing software products you have to read this book and make sure you don't make the mistakes he describe, such as Wordstar trying to sell 2 competing products, yes thats right, 2 word processors, both different, both word processors. You laugh now, but they really did try and do it, and thats why Wordstar doesn't exist and we have to use Word I was on the OS/2 team in the late 80s and it was light a trip back to memory lane as I watched IBM become totally shafted by Microsoft, and do nothing about it because it thought it was better than Microsoft. lol, how we laugh now....... Tuesday, November 4. 2008Dreaming In Code - A Review
I've just finished reading Dreaming In Code by Scott Rosenburg
While trying to write a review on Amazon I struggled with whether to give it 0, 3 or 5 stars, let me explain First the book is about the development of Chanlder, a next generation PIM sponsored by Mitch Kapor, ex Lotus Chief and with some of the big names in software development and open source, including Andy Hetzfeld whold wrote most of the original Max UI code. What strikes you while reading this is what a complete disaster the project was, they seem to spend weeks if not months "thinking" about the design, navel gazing like never before. The book seems to suggest the designers never once tried to use actual customers or possible customers to understand the problem domain but instead came up with wierd and wonderful designs from the UI down to the lowest level code, most of which were near impossible to implement The author then goes on to suggest, many times in the book, that software is hard and thats a fact. My god, its hard the way these people tried to develop it. On the back of the book I downloaded Chandler, and what a waste of several man years, and several million $$'s its basically a very bad PIM that is barely intuitive, slow and to be honest a bit c**p. So back to the review, if you want to read about the trials and tribulations of a complete mess of a software project, buy this book, 5 stars If you want to read about how not to design and develop software in the current internet age, buy this book, 5 stars If you want to read about how some of the apparent great minds in open source, are not really that great at working as a team in a real company, buy this book, 3 stars If you want the author to describe every computer programming term in the most basic definition, buy this book, 2 stars If you want to learn how to write great software, don't buy this book, 1 star Poor people, you really did get it wrong Monday, November 3. 2008
Agile, NFRs and the role of ... Posted by Keith Sterling
in Agile at
10:09
Comments (0) Trackbacks (0) Agile, NFRs and the role of Architectural Governance
Time and time again I come across the question and related issues of how does Agile deal with NFR's ( or Non Functional Requirements ). Those requirements which are often impossible to capture as stories. I have seen some teams ( and even tried my self early on ) to write stories such as As a <
I've become increasingly in favour of the use of architecture governance where by there is a specific role defined within the team who owns NFRs, and is responsible to ensure that they are adhered to within each story. The best solution I've found is that the Architect responsible for NFRs have an responsibility to ensure that each story is reviewed at some point with a view of the NFRs and the specific requirements are then capture as Acceptance tests on the story. Any story with data can state a critieria demanding Oracle, any story with UI can refer to usability tests Issues with this approach 1) Large agile teams may require more than one named architecture resource 2) Small agile teams may have this as a part time basis 3) Inexperienced architects may apply all NFRs to all Stories to "cover their backs" Monday, November 3. 2008Agile, NFRs and the role of Architectural Governance
Time and time again I come across the question and related issues of how does Agile deal with NFR's ( or Non Functional Requirements ). Those requirements which are often impossible to capture as stories. I have seen some teams ( and even tried my self early on ) to write stories such as As a <
I've become increasingly in favour of the use of architecture governance where by there is a specific role defined within the team who owns NFRs, and is responsible to ensure that they are adhered to within each story. The best solution I've found is that the Architect responsible for NFRs have an responsibility to ensure that each story is reviewed at some point with a view of the NFRs and the specific requirements are then capture as Acceptance tests on the story. Any story with data can state a critieria demanding Oracle, any story with UI can refer to usability tests Issues with this approach 1) Large agile teams may require more than one named architecture resource 2) Small agile teams may have this as a part time basis 3) Inexperienced architects may apply all NFRs to all Stories to "cover their backs" Thursday, October 23. 2008
IT Chiefs Don't Care About Software ... Posted by Keith Sterling
at
09:45
Comments (0) Trackbacks (0) IT Chiefs Don't Care About Software Quality
New survey by Four Hundred Stuff states that 40% of CIO's and IT directors don't care about quality, or the quality of their products.
While I am not surprised its not difficult to understand. In a past life I worked for a company, who's UK Managing Director was more concerned about hitting the deadline he has personally agreed to than ensuring that what went out was the best quality possible. His view was that the maintainence agreement was there to deal with that. Suffice to say we soon parted company.... A year or so later I was working for a major telco, who's CTO/CIO was happy for systems to be 80% complete and for the bugs and additions to be added once its live, on the assumption they had got the most important 80% and customers tolerate bugs on new systems. That was more worrying, but I've seen it more and more, senior managers assume software is buggy, and assume users accept buggy software because that is the status quo and therefore it acceptable to deliver buggy software and round we go again.... Wednesday, October 22. 2008New Website for Agile Tools
From the Yahoo Group Scrum Development comes a post about a new website for Agile tools http://www.userstories.com/
This is a new site but is dedicated to providing resource/reviews and product listings on the range of agile planning and management tools on the market. It looks good, but time will tell if the reviews are truly independent or become a way for people to publish they own tools SPAMMERS - I don't know why but this entry seems to be particularly appealing to you people. Unfortunately the only way to post is to first create an account, and account creation requires validation, which you will never get, so go away before I hunt you down........ Wednesday, October 8. 2008Can you be Agile without TDD ?
Before I even pose the question, I know what my answer is personally, but I'll leave that aside for now, and before I provide any more information, lets not worry about the differences between Test First and Test Driven Development, lets just agree that it means code with tests.
The main driver for the question is 2 fold :- 1) Past experience of 2 projects have made me question whether people believe this. A most recent project for a major financial institute had me coaching a development team who's department had a very strange approach to unit tests. While the developers always attempted to write them, they did under the knowledge that a) as soon as the deadlines loomed project managers would drop the need to fix unit tests for defects, in preference to just fixing the code, and b) as soon as the project was completed the unit tests were abandoned as the teams split at project end and rarely came back together. The problem for the coach ( me ) was to convince them that as they were part of an agile project, it should be assumed management would not abandon the principles at the end and therefore unit and component tests are a good thing. On another project, I inherited an Agile Team, who while where very vocal about iterative development, left defects to the end of the project, and rarely practiced unit tests, but regularly stated their Agile credentials. 2) My second issues comes from research I have being doing on Linked In. This is more of a sensitive issue, knowing personally or professionally a number people in Linked In who use Agile Coach as their title, I know a small number who either don't get or don't coach TDD, it makes me question what Agile message is being presented. Finally the who reason for this discussion is after overhearing a discussion at lunch time between a group of developers from a agile software company discussing how they didn't like TDD. So can you be Agile without TDD ? Tuesday, October 7. 2008BT adopts agile programming
Excellent article on The Industry Standard about how BT adopts agile programming which briefly touches on the mindset changes that needed to take place at BT for them to adopt agile methods
|
Calendar
QuicksearchArchivesCategoriesSyndicate This BlogBlog AdministrationTop Referrers |
|||||||||||||||||||||||||||||||||||||||||||||||||
