I’ve always been a firm believer that whether you’re Agile or Traditional, it’s important to postpone describing technical details as long as possible. It’s very tempting to start to solve problems ASAP, because there is something very satisfying about solving puzzles. Also, many project managers and others who are being held to deadlines will push to start design and coding as soon as possible. However, I believe in, as someone I met recently described it to me, a “back to basics” approach.
One challenge I often face is when a client pushes for me to start technical discussions with the users. Their argument Continue reading
I’m going to make a bit of a radical proposal here. I propose that we add the following to the Agile Manifesto:
We value interpersonal skills over technical knowledge
I’m not really proposing that we change the manifesto. I’m also not stating that technical knowledge is not extremely important. Remember that the Agile Manifesto states that we value the things on the left more than the right, but we still value the things on the right. I’m just making a point that I think a lot of organizations miss that affects their ability to really get the most out of Agile and Scrum.
As it’s been a few weeks since my last post I thought that I’d write about what’s been keeping me busy lately.
A few weeks ago I did a webinar with IAG about the role of a business analyst in an agile environment. We discussed some of the common misconceptions about Agile, why having an analyst on the team is critical in many organizations and then gave some tips and guidance for being successful as an analyst on an Agile team. I’m told over 600 people attended the webinar live.
On the topic of public events, 3 of my recent blog posts on user stories, use cases and requirements have been picked up by the Business Analyst Times. The first was posted on their blog section and was highlighted in their promotional material this week, and the remaining two will be published in the coming weeks.
The third area that has been keeping me occupied is improving my technical skills. I’ve been finishing up a few projects that I started to refresh my knowledge of Java and SQL, as well as learn new (to me) technologies like JQuery, App Engine, Python, Django etc. You can see the results of some of these projects on my site www.nunucat.com. I’ve also been spending a fair amount of time on udacity.com, a Massive Open Online Course site that has some excellent courses in everything from Physics to Interactive Graphics to Psychology to Applied Cryptography to… Needless to say I’m addicted.
Requirement statements that begin with the phrase “The system shall” are often referred to as IEEE style statements, because they were recommended for specifying software requirements in IEEE standard 830, and still are in 29148:2011.
The IEEE standard for software requirements specification recommends this method as they have many advantages Continue reading
I find use cases extremely valuable for eliciting requirements. Focusing the discussion on the business process with an informal use case, where each step is simply a bullet point and we don’t worry about using correct use case terminology, makes it much easier to keep conversation on track and productive and helps clarify and avoid misunderstandings that often occur between stakeholders and development staff in requirements discussions. Continue reading
A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.
Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project. Continue reading
Historically the Business Analyst position has been a grab-bag of roles. In some organizations the position is effectively a power user who has expertise in one or two systems and is responsible for analyzing and delivering service requests for those systems. In other organizations the analyst is nothing more than a scribe, responsible for recording meetings and completing documentation. Still more are pure business experts who act as subject matter experts as a proxy for the business.
The founding of the the IIBA 9 years ago started to resolve this problem, just as the creation of the PMI helped define and standardize the project manager position and activities. However, Continue reading