Pam Stanton PWWCBA Skype Conversations

Learn more about this event by visiting Projectworld 2010 or signing up for the newsletter: Newsletter

"these interviews were originally posted on www.agilescout.com"

Ellen Gottesdiener - Agile Retrospectives

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

A retrospective is a ritual in which the project community:

Reviews the iteration/release/project story

Harvests the collective wisdom of the team

Tells the truth without blame or judgment

Identifies what to appreciate and improve

Understand and forgives its failings

Relishes in its successes

"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.

James R. Lucas - Team Paradoxes

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

"Working with people would be easy if it wasn't for the people."

"Competing ideas are not a problem to be solved. Competing ideas are an opportunity to be exploited."

The paradox management process:

Embrace - determine to fully accept and live both sides of the paradox. Take more risk and eliminate risk

Eliminate - Focus on identifying and ridding ourselves of weak, poor, and suboptimal ideas and actions on each side of the paradox. Centralize or de-centralize?

Enhance - Focus on identifying and optimizing the good, value-add ideas and actions on each side of the paradox. Have war-rooms and party-rooms. Give people margin to think!

Engage - Use innovation to consciously and systematically to merge the two sides of the paradox into a cohesive whole. Evaluate ideas.

Explore - Challenge the status quo by identifying new actions that grow out of the merger of the two ideas. Be consistent and change everything.

In summary, James reveals to us the need to embrace the whole picture. Paradoxes shouldn't be avoided, they should be embraced!

Arthur Shelley - Behaviors and Teams

[This article was originally published at AgileScout.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.”

Arthur’s slides are below:

Mary Gerush - Next Gen Project Managers

[This article was originally published at AgileScout.com.]

"It's time to paint a new picture of the IT project manager."

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.

Pam Stanton and Understanding the Human Side of Project Management

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

What is The Project Whisperer?

Helping teams to recognize and embrace the human dynamics of the workplace.

"A project team acts as a living, breathing entity that undergoes a physical and emotional journey."

Stage 1: Shiny Happy People

Project is chartered

Team is being recruited

Optimism reigns

Stage 2: Confusion Sets In

Ambiguity breeds fear

Leadership wants plan

Stage 3: Valley of Despair

Throwing it over the wall

Interpersonal conflicts

Oh crap! moment

Stage 4: Blast-Off!

Time to deploy

Still complexity, unknowns

Team may be nervous, want to delay the project

Stage 5: Cruisin'

Initial rush and crush is over

Things start smoothing out

Stage 6: The Long Tail

The project is dragging on

Stage 7: Movin' On

Project fizzles out

No one feels recognized

No feeling of success

Janet Bartz and Jane Shellum Video Interview PWWCBA 2010

"originally posted on agilescout.com"

Kathleen Barrett PMs and BAs Must Collaborate

Coming Together to Ensure Project Success - The joint collaboration between Project Management Institute (PMI) and International Institute of Business Analysts (IIBA).

Kathleen describes the PM & BA definition of roles:

• Project Manager - person assigned by the performing organization to achieve the project objectives
• 
  
• 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.

What Agile Scout liked about Kathleen Barret’s presentation:

Critical Success Factors for Effective Cooperation:

◦Clear, documented, and mutually agreed roles and responsibilities including: Project Management Plan, WBS, Project Schedule, Approach (PM/BA)
◦Constant and open communication
◦Active business sponsor engagement

Key Areas of Overlapping PM/BA Responsibilities:

◦Scope Management – Project and Product Scope (PM), Solution Scope (BA)
◦Risk Management – Risk (PM), Risk, Opportunity (BA)
◦Communication Management – Communication and Stakeholder Management (PM), Communication Plan (BA)
◦Requirements Management – Project and Product Requirements (PM), Solution Requirements (BA)
In Conclusion, Project Managers and Business Analysts must:

◦Understand key concepts in both disciplines
◦Define roles and responsibilities
◦Work through conflict with clear and frequent communications
◦Collaborate
◦Engage sponsor


[This article was originally published at AgileScout.com.]

Wisdom from Our Speakers Day 1 PWWCBA 2010

Here is a quick recap of Day 1 from the awesome speakers at Project World 2010






"Core of Agile is resurfacing and advocating business value." - Susan Block

"It's ok to do Agile with a little "a" try things if they work or throw them out. Only use pieces that work or provide value." Jane Shellum

"Be open to what the teams are saying. They come up with great ideas on how to do things." - Pam Johnson

"Make it ok to fail." - Janet Bartz

"If a problem arises, ask the team." - Dave Grabel

"Be Agile, don't just use Agile." - Manoj Vadakkan

Find out more about this event by opting into the email newsletters: Sign Up ProjectWorld

[This article was originally published at AgileScout.com.]

Questions for Our Panel Speakers

Including:

Manoj Vadakkan

Susan Block

Dave Grabel

Janet Bartz

Jane Shellum

Pam Johnson

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.

Question: Multiple customers and conflicting priorities? Does Agile 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.

[This article was originally published at AgileScout.com.]

Pam Johnson on Self Organizing Teams

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:

1. Better defined project initiation processes
2. Improve turnaround time for obstacle clearing
3. Leadership coaching within teams
4. Continued efforts to move from transactional leadership to transformational leadership
5. Continue to mature relationships with development teams
6. Get more granular with regard to defining roles and responsibilities for project managers, team members, and functional managers
7. Continued cross training - Become more generic and less heroic

[This article was originally published at AgileScout.com.]

Janet Bartz and Jane Shellum on Using Agile and Lean Methods

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

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: 

1. Solution Architect 
2. Business Architect 
3. Application Architect 
4. 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.

Dave Grabel - Globally Distributed Teams

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

Introduction

Dave is a "recovering command & control manager!" Nice to see a little bit of transparency in the beginning. Before Agile Dave lead effective waterfall processes. So what is the reason to go to Agile?

"Change was impossible midstream."

A Tale of Two Projects - Flipping the Agile Manifesto

Two projects that Dave is working on use Scrum, but not completely. 

1. Project A was a project team of 25 people converting classic ASP to ASP.net offshore. - Successful project.
2. Project B was a project team of 150 people doing over 1000 Visual FoxPro screens converted to JSP web pages using BEA web portal offshore. - Failed project.

"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.

Susan Block - Agile Requirements

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]

Introduction

• We will learn about Susan's transition from waterfall to Agile as an Agile business analyst
• Understand the differences for the requirements approach on an Agile project.
• Integrate best practices on an Agile project.

The Vanguard Group went Agile to shorten implementation cycle and to deliver most valuable features first. Makes sense to us, a great reason to go Agile!

Agile for Vanguard Group is:

"Better, Faster, Cheaper."

As an Agile business analyst, Susan tells us that back in 2007 a enterprise initiative was funded for a multi-year program and went Agile halfway through!

A life before Agile business analysis for many projects looks like:

• Project Charter
• Estimate requirements up front
• Negotiate requirements duration
• Produce a project plan for requirements phase
• Conduct requirements sessions
• Document detailed requirements in templates
• Go through a change control board for changing requirements
• Handoff to development team

After transitioning to Agile, Susan's team found that:

• Processes are responsive to change with iterative planning and smaller units of work.
• The teams have daily communication
• The teams are cohesive in that they are committed, accountable, and available
• During the transition, Susan's team stopped cold turkey their old ways and went Agile. Interesting point here!

Agile at Vanguard has successfully transitioned to Agile over three years and developed Agile training curriculum in-house! This is a great success story!

The biggest takeaway here is that it takes time to transition to Agile, three year transition is not to shabby.

Manoj Vadakkan on Agile Project Management Estimation

[This article was originally published at AgileScout.com. You can find them on Twitter at @agilescout]


There was a Time Before Agile: 

Before Agile most shops "gathered" requirements from the beginning.

UAT usually was an afterthought and usually left behind in the development process and estimation was done long before the work was even initiated. 

"The actual work always took longer to do than estimated."

Taking baby steps towards Agile:

• Start small with baby steps in fixed sprint length
• Run tests after each iterations
• Start estimation through user stories
• Get customer feedback

Manoj uses the following Estimation Techniques for User Stories:

• Planning Poker 
• T-shirt sizing 
• Ordered piles 

Manoj defines "Velocity" as how many story points a team can complete within an iteration.

How do you average your velocity?

1. Take out outliers (highest and lowest velocity #)

2. Take best velocity (after outliers taken out)

3. Take lowest velocity (after outliers taken out)

4. Have conversation with your customer around the lowest and best velocity after taking out the outliers. 

Not sure how to earn PDUs?

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