The Business Analysts as Scrum Product Owner

I migrated my BA Symposium presentation from powerpoint to index cards and a prezi.com file.  Prezi doesn't read like a book, so a stand-alone online reading doesn't work as well as Powerpoint files, but it sure does look neat.

• Check my Prezi presenattion out here.

BA Symposium, Sydney

I'll be speaking at BA World's BA Symposium in Sydney on Monday about how a BA can migrate into a scrum Product Owner role and sharing some experiences from my life. If you are there drop by and say hello.

(I'll also be at Melbourne the next week.)

The draft of the slide deck is below.  I'll probably be abandoning it though as I want to try out using a tool I saw at a recent Thoughtworks resentation called Prezi.  When I have completed the prezi file I'll try to post it here.

I'll also be sitting on a panel called BA-PM Turf wars.  The theme is as follows;

Ten years ago many organizations had no idea what a BA was! Today they employ many of them! The Project Managers are looking around and seeing a whole new role within a project – one that was sorely missing on many projects of the past. Or was it? Some project managers will tell you that the requirements gathering phase is their job. Some organizations will tell you that the PM and BA are one and the same. Others will bring it the business analyst and not even tell the project management community about them! Let the turf wars begin!

This is a similar theme as Elizabeth's Harrin's BCS talk in September.  What are your thoughts on this issue?  To me it smells like alignment issues again.

Business Analyst As Product Owner

View more documents from Craig Brown.

2 weeks of silence

I just checked my rss feed for Sydney project management jobs.  It's been quiet for the last 2 weeks.  Not a single pm job listed on Australia's leading job site.

Potentially there will be a flood of postings tomorrow, July 1, but it has been spookily quiet in the market.

In the meantime I just finished marking exams and loading up the scores on a borrowed computer.  Next task, get my machine fixed and get back to posting here.

Self managed self motivated teams

The management literature point at self directed and self managing teams as an optimal management style.  It's also embedded into the agile and lean software development models I am familiar with.

This is where you want to go.  This is how you want to direct your organisation (or in our case teams.)  And virtually all workers have the capacity to get there.

But where is the pathway from here to there?  You are running a project with a deadline and plenty of constraints.  You need to set some goals for your team and you need to direct them in their tasks to keep them on target.  And you need to psuh them at the deadline, otherwise they'll go over time and budget, right?

Maybe, but sooner or later you'll want to switch across to the self directed mode of getting things done.

Small steps of leaps of faith?  Which one is right for you?

Picture by t3rmin4t0r, CC @ Flickr.

The Professional BA

Kathleen Haas of Management Concepts deliverred this presentation last year.  Found on Slideshare care of Tom Humbarger.  It looks at a whole lot of stuff around defining the role and value of the busniess analyst. 

One particularly good features is a table defining competencies at various stages in your BA career.

The Business Analyst: The Pivotal Role Of The Future

View more OpenOffice presentations from Tom Humbarger.

Testing sacred PM practices

Jeff Edwards carried out a survey of project managers, exploring some of the presumptions about project management practices. He has written up a series of blog posts on 9 PM areas and found only two of them had a really solid contribution to project success.

A caution on the study - it was of a limited size.  It is worth taking a look at.  Start the series here, and finish here, with a short podcast.

Seilevel's ROM

Seilevel have published a Requireents Object Model (ROM).  This is similar to a Requirements Entity Relationship (RER) model Guy Beauchamp put together in 2007. 

Compare the two and offer your thoughts.

• Seilevel's ROM
• Guy Beachamp's RER
  

Either model is an interesting choice. What do they give you?

One thing is a pathway to ensure you have good coverage of the requirements, another is to ensure you have good alignment to the sponsor/business goals.

Email, Whiteboards and Well-Caffeinated Wits

This is a guest post by Jeff Hobbs.  Jeff is a project manager at ActiveState Software who provide pm and collaboration software.

Email, Whiteboards and Well-Caffeinated Wits

The culture of software development has many myths, but among its truths are that we’re a busy lot. Moving from project to project often has to happen so quickly that there’s little chance to take stock of what works and what doesn’t in the processes we follow and the tools we use.

That scenario probably feels familiar, but who hasn’t been eager to get started on the next great idea or the newest client with an almost impossible deadline that we’d love to meet? The love of making things and the pressure to keep moving can lead to some risky process decisions, especially surrounding the choice of project management tools. When ActiveState commissioned a survey to find out how developers are managing their projects, the extent of that risk and how far-reaching it is in the industry took us by surprise.

Our survey took in responses from a full range of software professionals, from one-person-shows to both small and large teams working across industries. Most respondents work directly in the IT industry, rather than in IT supporting another industry, and some 66% work in teams of under 10 people.

The first surprise was that only some 14% of respondents are using a dedicated project management solution. Surprising but not a bombshell by any stretch, because we know that specialized tools that can be used in tandem if there’s a process that stitches those tools together. Only some 20% of respondents are using those specialized tools to assemble their own ad-hoc project management system.

That leaves some 80% using little more than email, whiteboards and well-caffeinated wits to keep track of all the things that need tracking in a technology project. That number really surprises us, partly because we all know there are established names in project management solutions. But let’s face it: where mindshare isn’t translating into market share, something isn’t working.

The climb from barely organized to really getting things done as a team can look daunting from the bottom. But some small first steps and tips for thinking about the process of selecting methods and tools can make it easy to get under way.

Set Your Sights
Make a simple statement of the project goal, then print it out at a size that you can read from across the room and post it wherever work is happening, online or in a physical space. Having that common goal present in the team’s working context is a visible reminder of what’s most important, and a great touchstone for testing new ideas and decisions along the way.

The Real Team Energizer
Forget Red Bull, and throw out the Jolt. The thing that will really energize your team is making information critical to the project easily available to everyone in the project. With feature lists, discussions, schedule milestones and key decisions taken along the way, you’ll find the need to remind and re-hash established knowledge going way down. One thing that can be hard about opening up the flow of information in a project is stopping the email habit. Email is easy, but it can be a project killer by locking up crucial data in the recipient list. With a commonly-accessible store of project information, the walls between team members that we may not even see come down.

Don’t Rush into Commitment
Choose the tools that demand the least up-front effort to start using. Diving into a project management solution that requires hours of setup can give you a feeling of getting things under control, until you find that it just doesn’t work the way your team works. Choosing a tool that lets you start with a low commitment of time and effort, and that can grow as you find it more useful, will avoid wasting time on dead-ends that might be good for other teams, but not yours.

Ask Around
Talk to other software teams and find out how they keep themselves on track. If you’re already in a community that you like talking with, bring to them the question of how to evolve the way a team works. Pitch an ad-hoc discussion over drinks with some local developers working in teams of a size and nature similar to yours. Even if you don’t get the exact answers you need, it can feel good knowing you’re not alone in facing project management challenges. And you might make some new friends in the process, as a bonus.

Whatever course you choose, if you’re not using a project management process that’s working for your team today, the one thing that I can guarantee is that it won’t get better without making a change. And like crossing any distance, taking that first step gets you that much closer to project sanity than you were before.