<$BlogRSDURL$>

Wednesday, October 05, 2005



Agile Software Development
Training, Coaching, Consulting

Team Training
Project Startup
Process Improvement
Facilitation
Open Space Conferences
learn more



I am passionate about making work valuable and rewarding, and I thrive on helping teams and their customers discover the best ways to do this.

With over twenty years' experience in the IT industry, I know that process can help or hurt a team. I've mentored colleagues and improved the processes of numerous software development teams during my career, and have helped both adhoc teams and those with heavy PMO processes find balance and a renewed ability to produce quality, quickly.

From helping small teams to get started with Agile, to assisting with the enterprise-wide rollout of an Agile software development methodology, helping teams "make sense" of their work is what I do. My Agile2006 conference paper, emphasises that metrics must be appropriate to each team's context in order not to distract or mislead.

I am an active contributor to the international Agile community, notably as editor of the InfoQ.com Agile queue, and as co-organizer of InfoQ's international Qcon conference, where I collaborate with key Agile and Lean authors worldwide. I am a Certified ScrumMaster, an Agile Process Improvement Coach, and I facilitate OpenSpace un-conferences for the XPday North America team in Canada and the US.

For issues around on-time delivery, software quality or team morale, contact me to discuss how I can help your business achieve its software development goals.


Deborah Hartmann,
Toronto




Writing sensible email messages 

Just plain useful information. Thanks to Reg B. for the pointer to this item.
[ link ]

Friday, June 10, 2005

Please join me on my new blog VitalBrew 

Thursday, April 28, 2005

The Agile Business Analyst 

I've been reading and thinking on the changing role of the Business Analyst (BA), in relation to the structure of Agile teams. I've come across a number of teams reflecting on this very thing. This article reflects my own experience and also the recent discussions with and blogs by various Agile colleages.

When the customer and the team are in sync, the BA could only play a supporting role, I believe. For example, with XP, this is the situation where the Customer is happily on site and contributing. Within this model, the BA is least necessary. If all projects were like this, a BA would have to be flexible enough to play various supporting roles on the team, and let the team lead (or the team as a whole, depending on team structure) organize their interactions with the client.

However, where this ideal arrangement doesn't/can't happen, it seems there are two poles, and shades of grey in between, those two poles being:

A) the customer is very interested in the Agile approach, but not sure how to work with the team. Agile can mean big changes in their approach to requirements, design, testing. In this case, the BA acts as a coach to the customer, helping them make the transition and pitching in as a part of the customer team. This may include helping them transition existing processes into more Agile forms. The BA is essentially outside the development team, is part of the customer team as an assistant. When the BA acts as a customer (writing stories, testing, etc), they are simply providing manpower to the customer team.

Z) the customer has heard good things about Agile, believes we can bring them better value/quality for their money, but they are not interested (or allowed) to play by Agile rules. In this case, the BA probably has a dual role - as a translator, and potentially as a change agent. The translator role (called "the blocker" by Scott Ambler) runs interference between the style of the customer and the style of the team. This may mean re-creating deliverables (ex: rewriting Stories to meet some external requirements format), or proxying the client on-site. The change agent role is a more subtle one, and is simply a matter of making the virtues of Agile visible to the client, slowly over time - the objective being to reduce alienation and improve flow between the teams, not to convert the client! However, we know that the Agile approaches are seductive to those jaded by waterfall, bad RUP implementations, etc. ... so the BA, while proxying the client, should not be hiding the team's process but explaining it, showing the sense of it, in areas appropriate to the interests of the client. This is where we sometimes play the "don't tell them it's XP" game - using familiar terms to explain what we do, why we do it. The BA might need to be more prominent in communications between the team and customer - could even be the "face" of the development team, if that's what the customer requires. Whether you call the BA part of the development team or the customer team probably is a matter of semantics, and will vary depending on the customer. Scenarion Z seems the least Agile (most costly) approach, and more costly.

I'd assume that the majority of Agile projects fall somewhere between these two extremes right now. I do hear stories from across this spectrum within the Agile communities I frequent.

These variations in the customer-developer relationship seem to explain why an Agile BA needs so many hats! As a result, I've been reading on Org Patterns this year, particularly "Fearless Change" by Linda Rising. Across this spectrum, from A to Z, customer and developer teams will need to adapt, one way or the other, to work together. I figure we all benefit from learning to make change as painless as possible!

It's interesting that currently a number of shops are thinking about this subject. It comes up in discussions about testing, requirements, metrics, or politics. I've been invited to a two-day workshop in Toronto looking at "the role of testing on the Agile team" - once again, addressing these very questions. This year, I look forward to deepening my understanding of Agile requirements/testing on my path toward becoming an Agile process coach.

I would be interested to see what shape your BA solution has taken... we all need to learn from one another, in the Agile community! Please leave me a comment, so we can swap ideas!

Sunday, July 25, 2004

Collaborative writing on the web 

I find a Wiki problematic for certain kinds of tasks. But I thought, surely I'm not the first to encounter this, so I googled "co-write wiki" and discovered Blokis!
"A Bloki is a hybrid of a Blog and a Wikki which combines the ease of publishing a Blog and the collaboration of a Wiki. A Bloki allows you to "collaborate on shared documents, write a document and have others mark it up with their comments, or collaborate with others on the same document. You control who sees what and who gets to change your pages."
However, I created a Bloki and tried to play with it for a while, but found its ui inelegant and hard to figure out. I gave up in frustration when some of the popup windows didn't work with my FireFox browser.

Still, I think it's a good idea - are there other things out there like this?
[ link ]

Thursday, July 15, 2004

Simplicity and Complexity 

"Simple, clear purpose and principles give rise to complex, intelligent behaviour. Complex rules and regulations give rise to simple, stupid behaviour."

- Dee Hock, former CEO of Visa International

Wednesday, July 14, 2004

Coaching on Agile Teams 

Blogged under "The Psychology of Computer Programming", cites a post by Pam Rostal on Coaching. Includes useful article links. Thanks Pam! Enjoy.
[ link ]

Tuesday, May 11, 2004

duh ! ? 

"Good designers don't put handles on unlatched doors that can only
be pushed. Instead, they put a flat plate where the handle would otherwise be.
Just about the only thing you can do with a plate is to push on it, so the
physical structure of the plate helps you operate the door correctly."


--Object Oriented Perl, Damien Conway
[ link ]

Thursday, May 06, 2004

BlogThis! 

Wow, create Blog entries from your toolbar! Cool!
[ link ]

Wednesday, May 05, 2004

where bugs come from 

Software complexity, bugs, and metrics: Charles Miller writes an excellent piece on complexity. He suggests to use testers on projects, dedicated to testing the software at the functional level. Useful: Includes "failure conditions" for automated unit testing.
[ link ]