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

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

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

Live Webinar on Agile Adoption – Register Now!

Wednesday, September 26th, 2012

Join us for a free live webinar on agile adoption. Based on their recently published study on product  team development, Greg Geracie, President of Actuation Consulting and author of  Take Charge of Product Management, and Steven Starke, author of S.T.O.P The Project Management Survival Plan, will explore with you the recent trends of agile methodologies adoption in organizations.

Live Webinar: Thursday, October 11 at 12PM EDT (local time)

This webinar will cover:

  • Why only 13% of organizations use pure agile
  • The most popular methodologies used per company size
  • 5 key factors driving high performance product development teams
Read more about Greg & Steven

If you have questions for Greg and Steven, feel free to send them to us in advance to increase your chance of getting answers in the live Questions & Answers period at the end of the webinar. Be sure to follow #AgileAdoption on Twitter, on October 11 at 12 PM EDT!

Planbox Agile Adoption Agile Project Management Software

 

line

Agile Beyond IT (Part 2): Scrum in Manufacturing

Monday, February 6th, 2012

From inception, we wanted to build a flexible project management tool that would adapt to companies and departments that were not necessarily software development-centric.  Over the past months, we’ve noticed that Planbox is being deployed by a wide variety of companies.  In fact, our agile tool is being used in manufacturing, marketing, communications and many other industries.  This post is part of a series highlighting how some Planbox customers outside of IT development are using our agile project management software.

Matthews International Corp (MATW:Nasdaq) is a 160 year old manufacturing company. In September 2011 they were looking for solutions to communication bottlenecks between their engineering teams, marketing department and management that were slowing down production. They decided to adopt an agile methodology and settled on Planbox as their primary tool.

Planbox is a software solution that isn’t limited to the IT industry. Matthews International is an example of a manufacturer of durable goods who has embraced the flexibility and strength of agile project management.

Here is their story in the words of Mike Hinds, Vice President of Technology:

“When I started working for Matthews about 8 months ago, for the most part we had no process and were in reactionary mode on most projects. And we had too many projects underway. We weren’t getting things out the door and were suffering from major delays due to lack of communication. As a fan of Scrum and with a software background, I suggested Scrum as a means to conduct day-to-day project execution. We looked at a few Management tools and Planbox stood out, quite frankly, based on price. Let me clarify that we are a hardware/software based organization, so Scrum isn’t necessarily ideal for us, but I thought with modifications we could make it work. We have 3 main locations and are a 160 year old company, so I knew that change and adoption would go slowly. The Scrum meetings were like a breath of fresh air for most of the team. We had a bottleneck at the Engineering Management level, so the open communication was much needed. We literally had products being thrown over the fence to Marketing with no warning on what was coming. We weren’t executing as well as we could, seeing that we had a very senior and talented team.

As I introduced Planbox, it was painful at first but people started to see the value. And as a data hungry executive, I could start to see everything that was underway and could start to identify bottlenecks more easily using Planbox. And Planbox was very receptive to my requests for modifications that would specifically help our organization, not that my requests were unique.

So far I am very pleased with Planbox. It’s intuitive and is a great value proposition for companies like us that are implementing Scrum as a means to conduct day-to-day operations with much better visibility, minimizing surprises and being able to more accurately synchronize engineering and marketing activities.”

Mike Hinds, Ph.D.
V.P. of Technology
Marking Products Division
Matthews International Corp.

line

A Short Presentation About Agile

Tuesday, December 6th, 2011

I’ve recently been doing a lot of Planbox training and some companies need a quick overview or recap of agile. During these trainings, I don’t have time to go over all things agile, so I’ve done a short presentation that hopefully still covers the most important points about agile.

Let me know if you think some of the information I’ve put in about agile should be replaced by something more relevant. But remember, it all needs to fit in 10 slides!

I also give the companies who get training a list of resources they can refer to to learn more about agile.

Agile according to Planbox

View more presentations from Planbox

 

line

Agile Project Management demystified

Tuesday, March 8th, 2011

In the realm of Project Management, Agile remains a mystic branch that is both tempting and terrifying. Many a- Project Managers is intrigued by the benefits of the method and do not fully understand how its core principles relate to traditional Project Management… so let’s take a peek.

First and foremost Agile is an iterative process relying on a few principles –twelve in fact, namely the Agile Manifesto – and small yet highly adaptable teams. It’s an umbrella term for many management methods that have gained in popularity mostly in the tech industry: Scrum, Crystal, Extreme Programming, FDD, DSDM are all Agile methods.

Agile is usually associated with Software Development and/or Project Management but has lately gained a large number of followers as a Management philosophy with wider applications than Development and Project Management.

At the heart of Agile is Iterative and Incremental development. Agile encourages collaboration between cross-functional teams and is applicable to all types of industries. Teams are also self-organized and prone to quick releases of features.

We’ll explain in layman’s terms the different facets of Agile Management, starting off with a graph:

Agile Project Management Tool

 

Features – or Deliverables:

As a Project Management method, Agile focuses on delivering Features – or Deliverables – as often as possible. As part of the definition, the Deliverable must be Completed, Tested, Debugged and Usable.

Iterations:

Core to any Agile method are Iterations. Iterations are fixed-length periods of time, of 1 to 4 weeks (usually 2) during which we try to accomplish a list of things or deliver certain features.

The idea behind iterations is to give the team a short term objective that creates both a sense of emergency and a feeling of accomplishment once it is completed – an addictive cocktail. Short-term, achievable objectives help to keep morale high.

Releases:

Releases are a part of the Grander Scheme of things. A release usually consists of a few iterations, where many Features or Deliverables are sent to the client or put into production.

Stories:

Agile is highly customer-driven. Therefore, features are usually translated into User-Stories. A Story explains how a feature is to be used and gives it context. A proper way to write Stories is to start by:

As a User I want to … have access to my data online

As a Client I want to… have a billboard printed in Times Square

Backlog:

The Product Backlog regroups all the remaining Stories for a given project. The Product Backlog is meant to be properly maintained and prioritized. Once an Iteration is completed, stories are selected from the Backlog, based on Priorities and are sent to the new Iteration.

Prioritization:

There are many ways to organize the Backlog: Business Value, Point value and relative Importance are the most frequently used systems. Business Value indicates the $ value of releasing a particular Story, Point Value is an indicator of the relative difficulty of delivering the feature and Importance is a measure of how critical a feature is to the overall project. Put together, these indicators allow for a Cost/benefit analysis that facilitate the Prioritization process.

Agile Roles:

There are 4 typical roles in Agile. Product Owner, Project Manager, Worker and Stakeholder.

The Stakeholder is usually the instigator of the project or the investor.

The Product Owner is the Stakeholder’s representative. He is in charge of prioritizing the Backlog and Writing the Stories.

The Project Manager (or Scrum Master in the Scrum method) is a facilitator to the team. He organizes the team, removes impediments, oversees the process, manages the Sprint backlog and the overall progress of the project.

The Workers are the ones getting things done. They estimate the stories in points and the tasks in hours. If the stories are estimated to be too big for a sprint, they can request the stories to be broken down by the Product Owner.

Sprints:

The Sprint is the name given to the current Iteration the workers are involved in.

Cross-functional teams:

In Agile, teams are meant to be cross-functional. Here are a few examples:

Software:     Developper, Tester, UI dev, Designer

Website:      Copy Writer, Developer, Designer, Content Manager

Marketing:    PR, Designer, Copy, Event Manager.

Hardware:     Engineer, Industrial Designer, Tester, Supply manager

SEO:              Copy writer, On-site Optimizer, Backlinker, SEM manager.

Self-Organization:

Teams are asked to organize themselves by creating the tasks related to the stories and estimating them, whether it be by Estimated Hours or Value Points. They subsequently assign tasks among each other and launch the iteration.

PMBOK vs Agile:

In Project Management, there are always 3 aspects that are considered: Budget, Scope and deadline.

In traditional Project management, the Scope is fixed and Budget and deadline may vary. In Agile, the Deadline is fixed, but the budget and Scope may vary.

Essentially Agile allows you to adapt to changing priorities and to prioritize what has the most value.

Benefits of Agile.

Quicker Time-to-Market

Reduced Risk by Managing Uncertainty

Increased reactivity to changing priorities

Superior Productivity & Software Quality

Healthier Customer-relationship

Better Team Morale

In essence, Agile is NOT that different from traditional Project Management. It just builds on it and improves elements that were found to be inefficient or problematic, such as managing risk and dealing with changing priorities.

Hope this clarifies things. Post any follow up question here and I’ll answer them!

 

line

Agile: Top 10 reasons to love it!

Monday, February 21st, 2011

We recently had discussions with a group of Project Managers, some of which were highly familiar with Agile Project Management and some… not at all. The Agile-savvy PMs went on to describe why Agile is so great and this is summary of what they came up with!

  1. Everyone loves a quick-win - Rapid and regular releases keep team spirit high and team members motivated.
  2. Death of large projects - Large Projects are meant to be broken down into smaller, more manageable projects makes things less overwhealming!
  3. De-bugging not search-Waldo - Frequent user feedback makes it easy to find bugs and correct them as we go.
  4. Great vocab – Agile means regularly using cool words like Scrum, Kaizen or Kanban!
  5. Less #fail – Real-time interaction with a Product owner who makes sure that we’re building something of value that the customer needs and will use. Not a #fail.
  6. Mindless drones need not apply – Agile is integrating by nature. Everyone participates in the planning, estimating and general success of the project.
  7. Test by fire – Speed-to-market is much faster so we get to test our products on the end users quickly and can adjust on their feedback.
  8. Agile is more of a guideline than a set of rules – Agile doesn’t have rules engraved in stone. You can pick and choose different ways to apply Agile in your work environments. Agile is flexible!
  9. Uninspired? Google it – Agile has created a community of believers and contributors. Not sure how best to implement a facet of Agile? Google it, find answers and adapt them.
  10. All bets are off, no more – No need to put all your money and faith on Feature “Red33″. Project-course corrections are made regularly, after each iterations and even within iterations when needed.

Now, let’s iterate on this! Add your suggestions to the list.

line

My Product Owner is stronger than yours!

Friday, January 28th, 2011

Agile Project Management Tool

 

I did an extensive (although utterly non-scientific) survey of  friends,  developers, Scrum masters, Agile consultants and  clients of our agile project management tool.

I also tested Quora where I popped the question:

What do you never want to hear your Product Owner say ?

Here are the Top 11 things you never want to hear from a Product Owner:

  1. ‘Cause I’m the Product Owner – A Product Owner is collaborative by nature. He works with the team to decide what is to be done, so pulling that card might not be the greatest idea. The “this is a much higher priority” card however is free-game!
  2. This is non-negociable – 80% of the Product Owner job is negotiating – with priorities, with the stakeholders, team members, etc. Everything is negotiable… until the sprint has started.
  3. I don’t really care either way – The Product Owner cares about everything related to the product. With a passion. Not just the product. Client, team members, stakeholders, everything.
  4. The stakeholders will be happy – Aiming for Stakeholder happiness is a crappy goal. The product Owner’s job is to aim for end user happiness.
  5. Yeah, this is good enough – It’s never good enough. It has to be INCREDIBLE to be good enough. One of the PO’s hardest job is saying “no” to team members.
  6. I’m currently unavailable but leave me a message and…  - During a sprint, the Product Owner has to be available to answer the team’s questions about certain features. If he’s not, it becomes an Impediment and you don’t want impediments.
  7. I’m not technical enough – Product owners do not need to be technical or understand the technical details. They need to understand users and user-functionality.
  8. Just one last thing … – This is something a Product Owner should never say in the middle of a sprint! You’re not Colombo … your job is to prioritize the backlog! If something is so important it cannot wait until the next sprint – that’s fine, it happens – you need to review the sprint backlog’s prioritize and decide which stories you’re going to swap it with.
  9. What should we do next?What the hell are we paying you for? That is exactly why the Product Backlog needs to be in tip-top shape and ordered by priorities, we don’t add stuff randomly as we go!
  10. I don’t know my usersA Product Owner always strives to know his users better and make sure his product answers their need. ! It’s a challenge and what I want to hear is : What can we do to know our users better?
  11. The Product Backlog is fullSay that again? I’m thinking oxymoron here? A product Backlog is ever evolving and therefor, can never be emptied. You can decide that it will not add value to continue burning the backlog, but it is never full.

Can anyone add to this list? Whether you’re a Stake Holder, Scrum master, Developer, Engineer, Business Owner or executive, we all have something we don’t want to hear from a Product Owner!

Courtesy of Planbox – an Agile Project Management Tool that goes beyond software development. Visit Planbox to learn more about our company and our product.

line