ProjectWorld and World Congress for Business Analysts blog seeks to bring together all levels of project management and business analysis expertise, from diverse industries and perspectives, across business groups and information technology. Our goal is build successful collaboration and share content, best practices, techniques, and networking.

"The insights gained from the retrospectives are the basis for starting again."

What do we ask during a retrospective:

What did we do well that we might forget to do next time if we don't discuss it?

What did we learn?

What should we do differently next time?

What still puzzles us?

What needs more discussion?

Retrospectives need to have structure to them, but also flexibility to move and respond to changes:

Readying - Set the stage

Past - Gather data

Present - Generate insights

Future - Decide what to do

Retrospect - Close the retrospective

In retrospective of this talk, Ellen did a great job helping us understand a framework for holding a retrospective. To learn more about retrospectives you can visit Ellen's website at www.ebgconsulting.com.

"I'm the behavioral story guy. We must have conversations around behaviors in regard to projects."

"Just because you're at the top of an org chart doesn't mean you're the leader."

What animal do we need to be in business? How do we act?

Behavior drives performance:

Performance = Capability + motivation + influence + role

In summary, do you understand your cultural jungle of characters? Now you need to create an environment that connects with the stakeholders in effective manners. Don't align a lion with a mouse, but communicate wisely. Also, understand your teams social network. If you understand who talks with whom, you'll understand where influence lies.

All behaviors have a niche:

◦Not right and wrong behaviors – But there are misplaced behaviors◦Target right animal in the right context – To get the optimal outcome◦Change animals consciously and proactively – rather than subconsciously in reaction“Need to show that you are behaviorally adaptable in business so as to not be mis-characterized.”

Traditional project management has helped us build our world and these standards are entrenched in our IT culture. Today's project manager is skilled, trained, certified.

But are we successful? Data suggests the answer is "NO."

Project managers need to prioritize differently now.

Teams have changed in this brave new world:

Distributed globally

Culturally diverse

Multi-sourced

Cross-functional

Business and technology complexity is growing in this new world:

Mergers and acquisitions

Partnerships

Compliance

Diverse architecture

Integrations and legacy

New technologies (Cloud, open source, mobility, Web 2.0, social media)

In summary, the new project manager needs to hone their people skills and adapt to new technologies. The soft skills that a project manager has is absolutely crucial to the success of project managers in the new technology-driven world.

Business Analyst - practitioner who works as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals

"These are project role definitions, not job title or organizational role."

"We exist as PM/BA's to introduce change into organizations."

"The PM needs to be the critical liaison to the project sponsor."

Kathleen gave a very detailed but helpful talk about how Project Managers and Business analysts must work together. She outlined the PMBOK and the BABOK and how there was overlapping roles and "partnership collaboration" was essential for the success of PMs and BAs working together.

Question: How do you make sure that Agile isn't used as a fire extinguishing tool?

Answer by Pam Johnson: Understand the priorities first, go from there and don't fight fires.

Question: Where do you start estimating? How do you kick off the process?

Answer by Manoj Vadakkan: Estimation should continue as is if it's working. Try small projects and iterate on them.

Question: Can a project be too Agile? Moving ahead without enough requirements definition?

Answer by Manoj Vadakkan: It's like an iceberg. You start at the top (prioritized), and as you get deeper it can get bigger. That's fine.

Question: How can Agile techniques for integration and package delivery?

Answer by Susan Block: We have to understand how integration as a product is brought into development. Analysis exercise to elicit the stories to deploy the configuration or integration. Need to have stories to cover that work.

Answer by Pam Johnson: Bring all product owners in and have a prioritization session. If that doesn't work, escalate it up towards higher level.

Question: Is it possible to perform Agile business analyst tasks even when project is still formally waterfall?

Answer by Susan Block: I recommend that you look at your big requirements phase and break it down into prioritized functionality. What will add the most value? Maybe you can make the case to provide just enough requirements instead of "all."

Question: Does Agile make sense for projects without a major customer facing component?

Answer by Pam Johnson: Yes. Customers are whomever you're doing the work for. Can be internal.

Question: How do you get team members to work outside their primary skillset to enable swarming?

Answer by Susan Block: Very hard to do, but try leveraging a bonus criteria for team members who are stepping outside their role. Give a carrot of promotion or rewards as a motivator.

Question: Does the business have to colocate with the development team?

Answer by Janet Bartz: Shadow the business people. My personal view is you have to have the business people with IT. It's so much more powerful. You can feel that somethings different where we are. It's tangible. Forget the throw-it-over-the-fence mentality.

Question: Executive support and Agile. What actions would you recommend for teams who want to move to Agile but don't have the support of upper management?

Answer by Manoj Vadakkan: Ask the business the question of why they want to go Agile and what are the reasons?

Question: What kinds of IT software initiatives are not Agile-appropriate?

Answer by Susan Block: Support issues and infrastructure projects that are cut and dry.

Question: How do you get the business to let go of big business requirements documents?

Answer by Jane Shellum: Nobody likes fat requirements documents. They come out of fear of not having all your bases covered. Easy to let go once you understand how Agile works. No such thing as scope creep. Scope change. Then prioritize the total list.

Pam Johnson works with Scripps Networks Interactive and they have been doing Agile for 3 years with 30+ development teams.

Pam describes a well understood and fully functional Agile enterprise. A very good example of how Agile is done successfully in a large organization with many teams.

This was an interesting talk because Pam gives the audience a view of a very successful Agile enterprise. There were some interesting points to take away but many of the points were covered by previous speakers.

Pam's talk was a nice end to the main speakers in that it gave us a refreshing look at a very well oiled Agile enterprise. We hope for continued success for Pam and Scripps Network!

Some of the changes that the Scripps Network needs to continue to improve include:

Better defined project initiation processes

Improve turnaround time for obstacle clearing

Leadership coaching within teams

Continued efforts to move from transactional leadership to transformational leadership

Continue to mature relationships with development teams

Get more granular with regard to defining roles and responsibilities for project managers, team members, and functional managers

Janet and Jane come from two different areas of business for the Mayo Clinic. It's the business and IT joining forces!

"When the business and IT partner together value can be derived through collaboration." - Jane Shellum

The Mayo clinic employs several Agile techniques on their projects. They started by focusing on what it took to deliver value, used some (not all) Agile concepts, and built a "dream team" that would fill the Agile roles needed to ensure the project would move smoothly.

The roles they created included:

Solution Architect

Business Architect

Application Architect

Data Architect

"If what I have in the end is a shelf full of documents and no software - I have failed." - Janet Bartz

What is interesting about their experience is that even though their project is Agile, there are still remnants of the old waterfall method that are still necessary. Going Agile doesn't mean drop (all) the old ways of doing things!

What was also nice was a section on things that they are aware of that need improvement:

Technical debt reduction

Keeping technical architecture in mind

Some Keepers and Kudos from Janet and Jane include:

Adherence to fixed iteration schedule

Poster-sized schedule of features and sequence

Commitment to quality and testing early

Inclusion of senior software QA engineer from the beginning

In summary, the business and IT partnership is critical. Don't forget the basics of open, honest and transparent communication with leaders and teams, embrace change but manage it, recognize accomplishment, and finally, be Agile, lean, and in-control.

"Agile can be wrong, but it should only be wrong for two weeks. Because you retrospect every iteration."

If teams turn the Agile Manifesto on its head, it becomes ScrumBut.

Dave gives us an interesting story about the two projects and told us the differences between the two teams. It was an interesting take on how to contrast successful vs. failed projects for distributed teams.

"You can handle change by being responsive to the stakeholders needs, that's what Agile is all about."

The biggest takeaway would be that to work with overseas teams or distributed Agile teams, there needs to be some very solid processes in place to ensure your team is communicating and collaborating daily.

Thursday, November 4, 2010

We have the answer - EARN UP TO 36 PDUs/CDUs by coming to the PW&WCBA event. We're offering a NEW year-round comprehensive learning experience that provides more credits than any other event. Within one conference package, earn up to 24 PDUs/CDUs at the live event, plus gain up to 12 MORE credits post-conference through the new on-demand Web Seminar Series which is included in your conference registration.

PW&WCBA is geared directly to the discipline of project management and business analysis at both a micro and macro level.

PW&WCBA is the premier conference brand for advancing collaboration through practice.

Each program goes beyond the PMBOK® and the BABOK® and is structured to deliver cutting-edge content for you, your team and your organization. Our speakers urge you to move past the core fundamentals to address real world challenges.

So come to the event and earn professional development units (PDUs) to maintain your PMI certification credential