Being an ‘Agile’ Product Manager
Product development life cycle starts with finding and planning the right problem to be solved. Once enough research has been done, the product managers and other stakeholders come up with designing the solution for the problem. After the product management team gets enough information about how to proceed with the solution, they come up with articulating the requirement for the solution, and this is where ‘Agile’ comes in.
Agile is the guideline for the Project. In addition, the process that tries to accomplish this is Agile Process. Agile is based on the following principles, called Agile Manifesto:
- Individuals and Interactions Over Processes and Tools
- Working Software Over Comprehensive Documentation
- Customer Collaboration Over Contract Negotiation
- Responding to Change Over Following a Plan
Implementation of Agile can be through different agile methodologies and below are few of them:
- Extreme Programming (XP): XP makes sure to satisfy the client’s satisfaction by improving the communication, fostering simplicity, feedback and encouraging respect and courage.
- Scrum: Scrum is a subset of XP, and is a Light Weight Practice with Less Overhead, iterative and incremental.
- Lean Software Development: It comes from manufacturing domain and hence encourages eliminating waste and pro-lean.
- Kanban: Kanban encourages Just In Time (JIT) and Cross Functional Teams. Kanban works great alongside lean software development, precisely because it was made for lean manufacturing.
A product manager implementing any of the agile metrology needs to understand the different agile tools to plan, understand, and define requirements so to develop the software product.
Lets start off by understanding the different terminologies involved:
- Each project has a Process. In the Agile world its the Agile Process.
- The project is broken down into Phases.
- Phases have tasks. A task is defined as a small, manageable step of a project to be completed.
- A role is a duty that a person takes on, or plays.
- An output work product that was produced in one task could act as an input work product to be used in a subsequent task.
Work breakdown Structure: A Work Breakdown Structure takes one large work product, and breaks it down into smaller, manageable work products, into a hierarchy. Top-Down approach is followed for Resources and Bottom-Up approach for Tasks & Activities.
Estimates, Target and commitments:
- An estimate is a guess for the time it will take for your development team to complete a task. These should be based on some sort of data, like previous times of similar tasks
- A target is a point in the schedule to meet. This is almost an ideal deadline.
- Ideally we would want to discuss estimates with our development team and come up with some accurate numbers. We will also want to talk to our client about target dates. Then based on these items, create commitments with our development team and our client.
Understanding the Requirements
What are requirements and how it should be comprehended:
- These are the specific descriptions of the client needs.
- To make world-class products Product Managers need to understand the difference between Requirement Gathering and Requirement Elicitation, and always should do elicitation which is typically missed by new PMs.
There are different types of requirements like Business, Market, Functional and Non-Functional, etc. There different articles about the same, I have collated few of them:
What are the User Considerations?
Following needs consideration while understanding the requirements:
- Whether End Users are directly using the product
- Who are the Stakeholders
- Whether we are developing user friendly, intuitive user interfaces
- Whether we are designing for the different user personas. It’s been suggested that designing for the two extremes of the beginner and the expert is ideal, middle takes care of itself
- Whether we are considering human limitations. Some examples of human limitations are perceptual limitations, physical limitations, cognitive limitations, and cultural limitations.
- And lastly we should consider that human memory can hold five to nine items at a time
How to Involve Clients:
- PMs need to ask good in-depth questions, stay focused on the goal and purpose of the product. And need to try to stay as independent of technology as possible.
- They should constantly ask the clients ‘Why?’, like ‘Why do they want it that way?’, ‘Why do they need the product?’, ‘Why would anyone use it?’
- Open-Ended questions, other than yes or no questions should be avoided. For example, try to stay away from asking, what do you want? Or what are your requirements? These questions are a little too open-ended.
- They should try to suggest possible alternatives and politely highlight why their approach may not work.
- They need to create data driven decisions.
Expressing the Requirements
There are different ways PMs can articulate the requirements, mainly by:
1. Use Cases: A use case is a way to identify, clarify, and organize the details of a task.
2. Use Case Diagram: It is a simple pictorial representation of the user’s interaction of the use cases.
3. Wireframes: Wire-frames are the pictorial functional guide to the visual design and content to establish the basic structure of a page. I usually use Balsamiq to create wire-frames.
4. Storyboard: A storyboard is a sequential, visual representation of an interaction.
5. User Stories: User Stories are meant to keep all of the requirements of your system to a consistent format. They are easy to write, easy to read, and easy to evaluate.
Scoping the Requirements
The scope draws the boundary between what is in and what is out for the project. PMs needs to understand the difference between the project’s vision and its scope
To avoid scope creep, PMs need to:
- Manage expectations of different stakeholders
- Draw product boundaries
- Set priorities
- Always ask, “Whether the functionality is in scope?”
- Make estimates accordingly, and
- Evaluate the impact of the proposed changes.
An acceptance test is basically a check for whether a requirement is met.
A product backlog is a list of software features which you and your team intend to develop.
- Things like user stories, work tasks, knowledge tasks and bugs are included
- The initial user stories you write with your client are gathered together and placed into the backlog.
- It’s unordered lump of all the things which would ideally be built into the end product.
The daily stand-up meeting is a short everyday meeting, ideally during start of the working day. Each team member who works towards the completion of a given sprint needs to participate.
During this meeting, each team member should briefly provide the answers of the following three questions:
- What has (s)he accomplished since the last daily stand-up meeting?
- What is (s)he is going to accomplish until the next stand-up meeting?
- What are the impediments that prevent him/her from accomplishing his/her tasks?
The daily stand-up meeting should ideally not last more than 15 minutes. All the issues raised during the meeting need to be ignored and handled after the meeting.
Software Development in the agile world fundamentally has the project management phase called agile planning, where the different processes and timelines are defined. Then comes the specification phase, where requirements are formulated and designed, after that is the implementation phase, where software architecture is designed and the software is built and finally the verification and validation phase, where testing is done and the software is validated.
There are many courses, books and articles for the same topic and I am listing a few of them:
Agile is ideal for small teams but this gets highly cumbersome if the team size increases. Enterprise Agile (having team size greater than 80) usually leads to increasing project time-lines as large teams lack interactions and technical debt due to older codebases.