Bypassing Github’s Content Security Policy (Chrome extension)

Friday, April 19th, 2013

 

If you’re looking to integrate Github functionality with an agile project management tool, you’ll be happy to read that we’ve been keeping busy revamping our original Github integration (stay tuned for a launch date in the coming days).

If you are an extension developer, and you have read Github’s recent blog post on its implementation of a Content Security Policy, you may feel screwed.

Here is how we bypassed Github’s Content Security Policy with our Chrome extension:

Just modify the initial page request, and everything will be fine.

Here is our manifest:

Don’t forget the “webRequest” and “webRequestBlocking”  permissions in the manifest It enables you to intercept the HTTP response header before the page actually gets its. Here is the background.js source

It’s just adding “https://mysite.com” to the list of authorized hosts for stylesheets and scripts.

Enjoy :)

line

Join the Study of Product Team Performance and Let Your Voice Be Heard!

Thursday, January 17th, 2013


The survey is open from January 15th through February 28th.

Take the survey now: Product Team Performance

>> Take the survey now <<
Survey duration: 9 minutes approx.

Each year Actuation Consulting and Enterprise Agility undertake a global study of product team performance. This is the second year of the study and the amount of industry interest and participation continues to increase. This year the amount of professional associations, vendors, and promotional partners supporting the survey had doubled. The study is designed to closely examine the factors that improve or impede product team performance.

This study will assess the dynamics of product team performance and determine what factors impede or improve product development outcomes. For the purposes of this study, the core product team consists of product managers, project and program managers, user experience professionals, business analysts, development managers, and engineers.

 

This year’s sponsors include:

- The Association of International Product Management and Marketing (AIPMM)

- The International Institute of Business Analysis’s Chicagoland Chapter (IIBA)

- The International Project Management Association (IPMA)

- The Product Development and Management Association’s Chicagoland Chapter (PDMA)

- And Planbox

In addition to the sponsors, the study enjoys a unique and wide variety of promotional partners. These include: the Chicago Product Management Association and Product Camp, Global Product Management Talk, Lee Lambert of the Lambert Consulting Group, Orange County Product Managers, the Project Management Institute’s Chicago Chapter, the ProjectTimes, Product Management Talk, the Silicon Valley Product Management Association (SVPMA), the Software and Information Industry Association (SIIA), and the User Experience Professionals Association (UXPA).

As you can see the study’s ever expanding list of partners encompass product management, project and program management, user experience, business analysts, development managers, and engineers at all levels.

So, as the study enters its second year it now has all the core roles covered and we anticipate increasing last year’s level of participation significantly. Please take a moment and share your thoughts with us. We want to hear from you and learn more about the effectiveness of your product team!

 

You can take the survey today by clicking here. The survey is open from January 15th – February 28th or until there are 3,000 responses. Whichever comes first.

The study findings will be made widely available through the sponsors and promotional partners and at Actuation Consulting’s website.

 

Meanwhile, you may also learn about some of last year’s findings by viewing this webinar, presented by Actuation Consulting’s Greg Geracie and Steven.

line

Let’s End the Debate! Scrum Master versus Project Manager – Part 3 of 3

Monday, December 3rd, 2012

Missed the other parts? Read them here: Part 1 or Part 2

 

Organizational Agile Transformation – Big Bang Approach?

In my last post in the series, I thought I would have a little fun. I was recently talking with a peer about the challenges organizations face when rolling out Agile. He mentioned that he was talking to a client later in the day and wanted to know what my recommendation was. I said “in my experience, you have to take an agile approach to actually rolling out Agile to an organization.  Agile brings about change, and depending on the culture of the organization, it may take time to fully adopt. An incremental approach is the best way to roll it out.”

He asked, “what if the client wants to rip the band-aid off and roll it out all at once?”  I responded half-jokingly… “well it depends on how many bodies they want to leave behind in the process.”  However, the more I thought about his question, the more I wanted to challenge my initial answer.  Rolling out Agile in a big bang approach really seems counter-intuitive considering what we are rolling out. However, rolling Agile out iteratively brings up the concern on how well Agile can scale.  An Agile roll-out out to an enterprise can involve several hundred people made up of a multitude of cross functional teams. Should we expect Agile to scale to this level?

From my industry experience, I’m finding more and more CIO/CTO types wanting to take this big bang approach. They want to make the leap and they want to make it now! However, the approach we take for roll out can make or break its success.  Is the best approach in rolling out Agile to an organization done through actually running the roll-out like an Agile project or is a big bang approach better?

I’ve attempted to break down some of the key components of Agile to try and answer this question.

1.  Communication

Increased and valuable communication is a key Agile principle. Agile works great within enclosed teams of 10-20 people. Because of the smaller team size, most team members actually (dare I say) develop friendships.  Agile doesn’t necessarily work when thousands have to interact. It’s extremely difficult to get somebody from another geographical location, participating in a project, trying to be friendly, and trying to get information at request.  Agile just doesn’t seem to be designed to scale.

2.  Lack of documentation

Because of the increased communication and conversation, the need to document in an Agile project isn’t really required. Agile is very light weight and is about just enough documentation. However, at the enterprise level, rolling out a new methodology (Agile) requires communication to be crisp, coordinated, and concise. Because of the different perspectives, constraints, and cross-functional priorities, a roll-out needs to be managed very tightly. A roll-out of this size requires that things get documented. Again, I would have to say that running an enterprise Agile roll-out through Agile principles doesn’t seem to be the right way to go.

3.  Self- Organizing Teams

The concept of self-managing teams organizing around goals given constraints works excellent on smaller Agile teams of 10-15 people works. However, an army of people cross-functionally based and geographically dispersed, just simply needs some order in order to function healthy. At the enterprise level, lack of formalism doesn’t lower chaos, it actually ensures chaos.

 

All in all, I still came away thinking that my initial answer was correct. Either path likely faces the above challenges. It’s a question of what makes more sense for your organization and is likely to gain more support among leadership: rip off the band-aid, have short-term pain in the hopes of long-term gain; or pilot your way into it so as to manage the risk of disruption, but risk losing support if tangible progress can’t be demonstrated and other agendas begin competing for resources.

An enterprise roll-out of Agile, does require some up-front planning and clear communication and structure. Yes, a more pragmatic, iterative (RUP like) approach would probably seem to be the best way to go. I know I may receive hate mail on this one, but dare I say, I recommend running an enterprise Agile rollout through your neighborhood PMO. I’m actually blogging about the PMO’s involvement during an Agile transformation at http://www.actuationconsultingllc.com/blog/

 

Regardless of which path you take, be sure to go in with eyes wide open!

 

This is the last in a series of three guest posts on this topic from Steven Starke, author of S.T.O.P The Project Management Survival Plan and partner at Actuation Consulting. Steven StarkeSteven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Truven Health Analytics (formerly Thomson Reuters Health) and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development. Steven can be reached at Steve@actuationconsulting.com and networked with via his LinkedIn profile. Read more about Steven.
line

AutoVIN’s Agile Transformation Case Study: Questions & Answers

Monday, December 3rd, 2012

 

Last week, we hosted an agile adoption case study webinar. We invited Si Alhir and the AutoVIN team to speak about their experience as their company ventured into an agility transformation. The team members  share their perspectives from their different roles in the journey, and offer specific actionable lessons they’ve learned that you can leverage in your own agile transformation.

 

Watch the full webinar recording here. 

 

AutoVIN Agile Adoption Case Study

 

There was so much great content in the discussion that we didn’t manage to have a longer Question & Answers period. Si Alhir and his team took the time after the webinar to answer some additional questions. If you have more, please post them in the comments section!

 

Questions & Answers

 

Q. What was the initial planned timeline for the (AutoVIN’s) Platform project?

A. As the AutoVIN solution/platform is continuously evolving, there was not an “initial planned timeline” per se, but the objective of maximizing the efficiency and effectiveness of the team, capitalizing (between ADESA and AutoVIN) on the vehicle inspection and reporting platform, and integrating a more-agile team with other less-agile teams (and world).

Despite that there were no initial planned timeline, circumstances forced a timeline and change in scope. Being agile has allowed this to happen more easily because features were prioritized from highest to lowest according to usage and broken into smaller amounts of work.

 

Q. Was User Experience design part of this process? or only back-end work?

A. Usability / User Experiences is a facet of the Product Owner role and Define-Detail perspective (of the Define-Detail, Build, and Test aspects of the Team) was continuously considered. User experience was part of the process and was essential in the adoption of the rollout plan for the new platform. Technology should make it easier for the user.

 

Q. Can agile methodologies be used in bigger teams? Is there a team size limit? For example, in a company of about 250 employees?

A. Agile adds flexibility and improves communication through usable software. The flexibility comes from the smaller increments of work that allow the features to by more easily aligned with the schedules of other teams.

Agile and Agility readily apply to larger and smaller teams. Scaling is not problematic when approached and designed deliberately. See the car.com case study for more information.


Q. How can the use of virtual project management tools or issue tracking tools help in an agile transformation journey? (other than helping teams working remotely). Especially for different teams that are used to work on its own domain and has it’s own planning board of activities?

A. The virtual project planning tool should be able to make changing plans an easier task. Priority can change due to the many influences on a product/project and with any transformation journey there is a discovery process that should not be hindered by tools.

Tools are valuable when they advance (versus impede) healthy human dynamics (well-being) and don’t introduce or perpetuate unhealthy human dynamics in support of overall performance. The crucial question about tools is “why” (benefits and detriments), the other four Ws (who, what, when, where), and “how”.

 

Q. I understand you don’t want to stifle creativity in the software development process, but at where do you draw the line, so you avoid doing R&D while on a project? I’ve tried to keep R&D outside of the project.

A. R&D happens throughout the project. Some may be up front to get comfortable with the scope but an important part of the process is to allow yourself time to plan ahead. As with anything creative, it requires outside inputs or situations and the best way to find these can be through implementing and experiencing the results of the product. The best validation of a need is through use, just keep the features light to limit the risk.

The crucial question concerning Agility is “what is value” (and how is it discovered and delivered). Once “value” is recognized, all things are balanced against it, for example, how much capacity we have, how much value is needed now versus later, and how much can we offered to focus on R&D now versus later, etc. Technology research & product development and market research & product design are partners in the overall discovery and delivery cycles around value. The Value questions is paramount!

 

Q. If you could offer one key recommendation to others interested in becoming more agile or achieving greater agility, what would that be?

A. AutoVin team: “Go all in, don’t give up early or alter the process at first. It can be difficult to improve and enforce positive habits/behavior.”

Si: One key recommendation is focus on Agility (not merely Agile Development), and don’t get “caught up” in dogma!

 

Q. What was the most “surprising” thing about your journey?

A. The most surprising part was how much the process aided in the team dynamics and improved morale.

 

Q. If you could do one thing differently what would that be?

A. Starting the journey earlier. It may have changed the decision around the office closing.

 

Q. What was “easier” than expected? What was more difficult than expected?

A. Easier: Starting our first sprint/iteration after iteration 0 (Getting to work without a thorough plan and trusting ourselves).

Difficult: Working with a less agile enterprise. Everything seems like an emergency and outside processes seem slow. It requires more planning to account for the different paces (heartbeats) of a less agile organization.

 

Click here for the slides of the webinar.

 

Si AlhirSi Alhir is a Practitioner and Consultant/Coach (Transformation, Change Management, and Organizational Development).He has over three decades of proven experience in transforming organizations/enterprises by synergizing Business and Technology around proven industry-recognized & organization-tailored principle-based practices and by cultivating effective Communities (of Interest, Practice, Engagement, and Purpose) that sustainably deliver impactful results. He leverages a broad and deep background in all aspects of technology product/services management (planning, marketing, and sales) and engineering (development), including business development, client management, and consulting services. Read more about Si.
line

AutoVIN’s Transformation Journey: Integrating the Spirit of Agility and the Letter of Agile

Monday, November 26th, 2012

Agile is an umbrella term for Scrum, Extreme Programming (XP), Lean Development, and Kanban practices, which have roots in Agility or the “ability to be agile.” Scrum is a framework for organizing work; Extreme Programming (XP) is a discipline for software engineering; Lean Development is an approach for applying Lean thinking in software engineering; and Kanban is a method for enacting change. These approaches share a common value system, Agility, which emphasizes people, results, collaboration, and responsiveness. These approaches represent the “letter” of Agile and the value system represents the “spirit” of Agility!

Many teams and organizations enact Agile practices yet don’t realize the benefits — to accelerate time-to-market, manage changing priorities, increase productivity, enhance quality, further align Business and Technology, improve visibility, reduce risk, and reduce cost — and are then forced to confront embracing an Agility mindset while many other teams and organizations embrace an Agility mindset yet don’t realize the benefits and are then similarly forced to confront enacting Agile practices. This dichotomy between practices and mindset is a “chicken or egg” problem, and strictly enacting the “letter” or embracing the “spirit” is problematic. Merely embracing a mindset often delays demonstrable benefits and merely enacting practices doesn’t achieve sustainable benefits, yet authentic success involves integrating (not merely balancing or compromising) the “spirit” as well as the “letter” in adopting, scaling, and sustaining an Agility mindset and Agile practices, both within teams and across organizations where “the whole is other than the sum of the parts”, which fundamentally involves Transformation.

On November 28th, 2012, AutoVIN, The Automated Vehicle Information Network, a subsidiary of ADESA, will share how it achieved greater Agility by integrating the Spirit of Agility and the Letter of Agile! We’ll explore how management and the team aligned around the nuances of the business problem and the complexity of the technology solution to discover and deliver Value, and how the transformation journey interweaves business, technology, and culture.

 

 

 

Si AlhirSi Alhir is a Practitioner and Consultant/Coach (Transformation, Change Management, and Organizational Development).

He has over three decades of proven experience in transforming organizations/enterprises by synergizing Business and Technology around proven industry-recognized & organization-tailored principle-based practices and by cultivating effective Communities (of Interest, Practice, Engagement, and Purpose) that sustainably deliver impactful results. He leverages a broad and deep background in all aspects of technology product/services management (planning, marketing, and sales) and engineering (development), including business development, client management, and consulting services. Read more about Si.

line

Planbox is a Proud Sponsor of Agile Tour Montreal 2012

Wednesday, November 21st, 2012

 

Agile Tour Montreal 2012

 

The 4th edition of Agile Tour Montreal is coming up this weekend. As a member of the agile community in Montreal, Planbox is proudly supporting this annual event to learn and to share knowledge about agile methodologies.

Agile Tour is a series of non-profit events that is held around the world. Some recent Agile Tours happened in Lausanne (Switzerland), Guangzhou (China), Toulouse (France), Chennai (India), and much more. To see when an Agile Tour is coming to a city near you, visit their website.

Our team is excited the various conferences; we’re especially looking forward to the 2 keynote presentations by Philippe Kruchten and Rémi Tremblay.

Philippe Kruchten’s presentation, titled “Games Software Folks Play”, will address how knowledge and critical thinking will allow people to make wise decisions, and how political games within organizations is nuisance to the process.

Rémi Tremblay’s presentation, titled “Peace and performance”, is about finding a balance between inner peace and performance. He will take us on a journey to explore our inner self, and to reflect upon 3 great human qualities: bravery, modesty and love.

Agile Tour Montreal 2012 Keynote Speakers

The Planbox team will be at the event filming and interviewing; if you’ll be there, please don’t be shy and come say hi to us!

To the rest of you, do you have questions you would like to ask guest speakers? Let us know in the comments below and we’ll go interview them for you.

line

Let’s End the Debate! Scrum Master versus Project Manager – Part 2 of 3

Tuesday, November 13th, 2012

Missed part 1? Read it here: Let’s End the Debate! Scrum Master versus Project Manager – Part 1 of 3

 

Over the past couple of months, I’ve been documenting, in near real-time, the progress being made as an organization goes through an Agile transformation.

 

During this transformation, I’ve learned that there’s no way, going through Scrum Master training that I could be responsible for all the responsibilities of a project manager. It’s just not fathomable and would lead to ultimate project failure. To set the record straight, project manager is NOT synonymous with Scrum Master. A Scrum Master is critical to the facilitation and execution of the Scrum team. But they’re not responsible for all the components of a product development project. If anything, a Scrum master should be a dotted line to a project manager as part of the reporting structure.

 

However, for all these relationships to work together, we also need to know what the responsibilities are of the team back to the project manager.

 

Essentially, the project manager has to know just about everything that’s going on during the course of a project in order to determine if the right action and the necessary progress is being made against the tasks and deliverables. It’s unrealistic for every meeting and every action to be in the project manager’s schedule. However, they still need to know what meetings are occurring and when communication and decisions are expected in order to ensure the team is working effectively and efficiently relative to the agreed upon scope and success criteria of the project.

 

This relationship between the project manager and the team is not meant to be based on command and control, but rather based on trust and optimizing collaboration. If the project manager has any chance in managing these responsibilities while not having authority over most, if not all, of the team resources, then they need to rely on those team leads for basic and fundamental information. The following are the characteristics of the entire product team including the project manager:

  • Openness regarding truthful task and deliverable progress
  • Frequent and constant communication
  • Commitment to achieving the success criteria
  • Courage to tell the truth
  • Respect for each other

 

Borrowing the page of Scrum team responsibilities to the product owner and scrum master, I’ve tailored the responsibilities so that they reflect the entire project team relative to the project manager:

  • Communication regarding the prioritization (and change) of requirements, MMF’s, sprint backlog items, and tasks
  • Commitments to results based on agreed upon milestones
  • Communication of estimates of effort to implement User Stories and tasks to complete all project deliverables
  • Communication of dependencies between tasks and team members
  • Identification of obstacles and informing the project manager when those obstacles may occur and when they have occurred.
  • Self-organizing – Individual teams within a project have to be self-organizing and can’t rely on a command and control style project manager. However, self organizing means informing the project manager on how the team is self- organized and how they intend to complete the work. Project manager’s need to have context for any of this to make sense.
  • The team has the right to do everything within the project guidelines boundaries to achieve the project goals.

 

In the product development world, project managers, more than ever, are critical in the successful execution and delivery of projects/products to market. Role clarity and collaboration is essential. The project manager and the scrum master are meant to work collaboratively with each other not against each other. If we can get our definition of a project correct and we can enforce the responsibilities of the team back to the project manager, then I can say confidently “Project managers, there is no need to worry about job security. You’re still a valuable member to your organization. If anything, your job just got easier by the introduction of the scrum master and product owner roles.

 

Don’t forget to leave your comments below! Thanks!

 

Continue reading: Let’s End the Debate! Scrum Master versus Project Manager – Part 3 of 3

 

This is the second in a series of three guest posts on this topic from Steven Starke, author of S.T.O.P The Project Management Survival Plan and partner at Actuation Consulting.  

Steven StarkeSteven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Truven Health Analytics (formerly Thomson Reuters Health) and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development. Steven can be reached at Steve@actuationconsulting.com and networked with via his LinkedIn profile. Read more about Steven.

line

List of Tools We Used to Create Planbox

Tuesday, October 30th, 2012

Recently, we took a look back at the beginnings of Planbox. Because improvements are done gradually through each iteration, sometimes, it’s easy to lose track of how much growth our app has gone through. It feels a bit like taking a look at your childhood pictures and having a warm fuzzy feeling at how mom had dressed you up.

Watch out for our next make over, it's coming soon!

 

We are very proud that Planbox has been the agile project management tool to help many teams plan and work through their projects. On our end, since our inception, we’ve also progressed significantly with the help of other tools. We made a list of apps on BestVendor.com to share with you the secret ingredients behind Planbox!

 

List of apps that helped us build Planbox

 

line

Let’s End the Debate! Scrum Master versus Project Manager – Part 1 of 3

Monday, October 22nd, 2012

Over the past several years, there has been much debate and confusion over the role of a project manager as the majority of organizations undergo some degree of Agile transformation. In fact, industry data suggests that approximately 53% of organizations are blending Agile methods with Waterfall.[1]

I can’t tell you how many articles I’ve read, and LinkedIn postings I’ve seen, on these subjects. The best material recognizes that a project manager is NOT a Scrum Master and vice versa. And although the description of the Scrum Master role is usually pretty clear in these discussions, nobody has done a really good job of explaining how the two roles (Scrum Master and Project Manager) co-exist or how this role confusion started in the first place.

To be honest, I really never understood the debate until recently as my organization decided to embrace an enterprise agile transformation (which I’ve been blogging about at http://www.actuationconsulting.com/blog/).

I started executing projects back in 2001 using XP (Extreme Programming) and I never had any issues with team members regarding role confusion during project execution. Agile wasn’t evil – Agile worked. Well, fast forward to 2012 and the debate continues to rage on. I finally got sick of watching the continuous debate and decided to take action. I took the classes, passed the test, and became a Certified Scrum Master. And after that investment of time and money, I can honestly say with certainty, I’m not a scrum master – I AM a project manager!

Fundamentally, I think the root cause of the debate is not based on scrum master versus project manager responsibilities but based on our fundamental definition of a project. In the Agile world of minimum marketable features (MMF’s), product backlogs, and continuous integration, the lines of the traditional project have now been blurred.

Let me get some quick definitions on the table to help structure our conversation:

The Scrum MasterThe Scrum Master focuses on the development process and mentors the Scrum team. The key responsibilities of the scrum master are:

  • Maintaining and removing impediments
  • Managing the Scrum process, making the process work
  • Planning the release
  • Planning the Sprints
  • Shielding the team from external interfaces
  • Facilitating Scrum meetings as requested
  • Ensuring crystal clear communication among everyone involved in the project

A Scrum Master is usually the team leader. A Scrum Master should ideally have a good balance of the following skills:

  • Technical expertise
  • Understands the Product Owner’s intent
  • A good team player and mentor
  • Understands the teams capabilities
  • A good motivator
  • Problem solver

Now let’s take a closer look at the program and project management roles and responsibilities by defining a project and a program…

Project: A temporary endeavor undertaken to create a unique product, service, or result. At most organizations, the boundaries of our “temporary endeavors” are defined through our business cases.

Program: A series of related projects designed to achieve a specific outcome(s).

To state it concisely, the role of the project manager is to manage all (ideation to post-launch support) aspects of the project to achieve the expected outcomes identified within the established business case (investment) – not just the Scrum team. The size, scope, and complexity of the business case will determine the size of the project. Achieving outcomes called out in the investment may take a series of related projects – called a program. At which point, the program manager is now accountable for managing all aspects of the program, with project managers and other accountable resources managing their smaller project portions.

Right now, there are three, possibly four basic categories of “temporary”:

    1. Product line execution – Temporary relative to a 1 year planning cycle. Basically covering minor incremental enhancements to an already existing product line.
    2. Big custom projects / new product development
    3. Within the product line – Specific temporary initiative/projects. For example, a SQL server upgrade.
    4. Cross organization initiatives – Examples that come to mind are rebranding, ICD-10 (healthcare), data center migrations, etc.

These projects / temporary endeavors at most organizations typically look like this:

Program Management View
And it looks like this…

Alternate View

If this is a project, then the project manager needs to be the one accountable person responsible for managing all of this work (or for understanding and managing HOW we’re going to get the answers to the questions above in each circle) – They are not responsible for answering the questions!

To put it simply – the project manager is responsible for managing all the boxes together to achieve the desired outcome. They may or may not be responsible for managing the individual boxes. Individual box responsibility is typically done by the subject matter experts.

As you can see, Agile development and the Scrum team are only one box!

Specifically, the project manager is responsible for:

  • Understanding the intended outcomes of the project and ensuring the outcomes are realistic and measurable. They need to understand the outcomes expected from the business case!
  • Collaborating with the team to define the scope of work (e.g. under each colored box above, what’s in it, what is the expected outcome), who is responsible for delivering it, and when will it be delivered. Specifically:
  • Understanding the point person from each functional team(s) associated to the work (each colored box) and how they have been allocated for managing their work. If allocation bandwidth issues exist, this person would be responsible for facilitation and ultimate resolution of the resourcing issue.
  • The job of the project manager is to remove ambiguity in roles and responsibilities by clearly mapping out activities against expected outcomes relative to time. Identifying the interdependencies between deliverables and functional teams up front will better determine what teams should be more integrated and when, relative to the overall product development process.
    • Deliverables required to complete all the project work
    • Cross-functional resource assignments
    • Estimates to complete the work and dependencies between work items

Important note: if the scope of work is large enough, another project manager/person may be assigned to specific items (smaller box). The relationship would be a dotted line from this other person to the project manager.

Said another way, if each one of the smaller boxes above is large enough in scope to be considered its own project, then the program would consist of several related smaller projects rolled up underneath the program.

    • E.g. Hardware or software procurement, installation, and configuration – Application Operation Project Manager
    • E.g. Agile product development – Product owner/scrum master
  • Understanding the process and tools required to manage the scope of work relative to the outcomes identified in the business case. Understanding the metrics and the process for achieving those metrics/goals.
    • If an identified metric is that the project be completed within a certain capital budget, then the project manager is responsible for understanding the tools and processes required to forecast and track the work. They are NOT responsible for creating or establishing those processes – unless of course that creation has been identified as another project!
  • Project managers are responsible for the overall communication regarding the project (not just the development portion of the product). They’re the primary single authoritative source of information to ensure a shared understanding of all parameters:
    • Scope
    • Cost management
    • Timing
    • Assumptions / constraints
    • Risks / issues
    • Resources
    • Quality
    • Special considerations / exceptions
    • Development methodology considerations
    • Team members and associated roles and responsibilities
    • Policies and procedures

So, if you agree with all of the above, is there really a debate between the two roles?


[1] The Study of Product Team Performance, 2012, Actuation Consulting LLC and Enterprise Agility Inc.

 

Read Let’s End the Debate! Scrum Master versus Project Manager – Part 2 of 3

 

This is the second in a series of three guest posts on this topic from Steven Starke, author of S.T.O.P The Project Management Survival Plan and partner at Actuation Consulting. Steven StarkeSteven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Truven Health Analytics (formerly Thomson Reuters Health) and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development. Steven can be reached at Steve@actuationconsulting.com and networked with via his LinkedIn profile. Read more about Steven.
line

Agile Adoption Webinar (Part 2): Infographic

Wednesday, October 17th, 2012

Last week, Planbox invited Greg Geracie and Steven Starke from Actuation Consulting for a live webinar about agile adoption. The webinar was based on their recently published study, in which they uncover 5 common key factors that were all present in high-performing product teams. In addition, they authors discuss recent trends in project management methodologies.

 

Watch the full webinar recording here. 

 

In this second part of a series of 2 blog posts about the agile adoption webinar, we present you a quick summary of the important data that was shared during the presentation.  If you like it, remember to please share it!

 

Agile Adoption Infographic by Planbox

 

You might also be interested in:

Agile Adoption Webinar (Part 1): Questions & Answers

line