How do your requirements smell?
While delivering the Business Systems Analysis course today one of the participants asked about the FRUEMP acronym (ISO standard 9126: Functionality, Reliability, Usability, Efficency, Maintainability, Portability) for requirements types – he suggested PERFUMe instead, which brings to mind the…
Changes to the Business Analyst role
With the rise in the take-up of the Agile approaches, one of the most common areas of confusion is the changing role of the business analyst.
I feel that the fundamental nature of the role doesn’t change – ensuring the customer voice is heard and business value is protected. The the way we do…
High performance teams emerge
Something that came across to me last week when delivering a suite of Agile courses is how high-performance teams emerge. One day of the course covers the identification of requirements as stories; to help make it real we used two actual projects that the customer is about to start. They are the…
Common testing issues
What are the key things that we find are issues for software testing? How can we address these problems? In my experience we usually have a solution to most of the problems – we just need to identify the problems and then we can workshop the solutions!
Here is my top 10 problems:1. late delivery of…
Don’t start until you know when you’ll be finished!
One of the best articles on project management I’ve come across over the last couple of years is this one from CIO magazine.
The author makes some great points about making sure you understand what the project sponsor will measure success by. He makes the distinction between a project that build…
Agile (note the big A) versus agile (note the small a)
I picked this one up several years at one of Software Education’s Software Development Conferences. I think it might have been Steve Mellor who said the worst thing to happen to agile was when it was re-spelled Agile.
I think that “agile” (note the small a) is the application of the commonsense…
Testing is NOT Quality Assurance!
Time after time we see testing referred to as Quality Assurance – indeed I read an article lately that said that the ISTQB definition of testing is essentially quality assurance (IEEE Software July/August 2009 – Reach for Standards, Good Ones by B. Meyer). I find this fascinating as it is one of…
More on Agile and “failure”
I agree wholeheartedly with the points raised by several people about the definition of project failure. I think it is commonsense to cancel a project once it is realised that the business case is poor or unrealisable.
A significant question to ask is, “How often is the business case expressed in…
With freedom comes great responsibility
Whatever life holds in store for me, I will never forget these words: “With great power comes great responsibility. ” This is my gift, my curse. Who am I?
As with Peter Parker, I see the same holding true with Agile testing. I was recently delivered a course on Agile testing and I…
The importance of WHAT not HOW when stating Scope and Requirements
Have a look at following two references from CIO magazine.
They support my arguments about the importance of using scoping techniques like the Context Diagram and the B5 technique. We should use these techniques, of course as part of understanding the “as is” business, but more importantly as a way…
Cultural change is not easy
Ken Schwaber (of Scrum fame) reckons that 75% of Scrum implementations will fail to deliver the anticipated benefit. This will most likely be because of the extent of cultural change needed for the organisation to adopt the new way of working.
I put an InfoQ news item that summarises the thought…
More on “failure”
CIO Magazine has an article on the Chaos survey results in which they identify that many of the “failed” projects have been cancelled because of recession-related factors (funding removed, staff gone etc). It says “Johnson [Standish Group chairman] estimates that 20 to 25 percent of the failure…