A major challenge faced in product development, especially with newly introduced products, is to validate whether or not the product solves problems and delivers value to it’s target group. It is common practice to develop products based on assumptions without involvement of real users. As a consequence the risks of failure and waste of costs is accepted. Even expensive market analysis cannot eliminate uncertainty about the product’s value to real users.
Obtaining valid feedback and learn from a product that doesn’t exist yet can be difficult, which leads to a high degree of uncertainty in terms of features the product should contain.
Why would you take that risks while real users are available to support you gathering insights and validate the product?
The concept of Minimal Viable Product (MVP) is highly beneficial when it comes to reducing uncertainty and develop products based on real user’s feedback.
…read full post
Many Project Managers often wonder whether it is worth getting the Project Management Professional (PMP) Certification from the Project Management Institute (PMI). This is partly due to the cost and the complicated examination and time involved in attaining the certification.
To begin with, the certification carries some amount of prestige and no doubt beefs up one resume. It is a huge asset to have as you advance in your career. It also enables one become better prepared to handle lucrative job opportunities. You are likely to be hired as a project manager over someone who doesn’t have the certification. A project manager with a PMP certification besides their name has extra credibility which is important when dealing with new clients. …read full post
Individuals and Interactions over Processes and Tools.
This statement is part of the agile manifesto. It highlights the importance of people and communication within the project. The key to understanding this statement is understanding the meaning of the word over. It may seem simple yet many people get it wrong. The word over is repeated four times in the Agile manifesto.
The word over in this context means that while processes and tools are important in software development, individuals and interactions are more valued. This doesn’t mean we do away with the tools and processes. Actually we cannot work without them, but we should put more emphasis on the people and effective communication rather than following rigid processes. Developers love their tools and processes as they help them get things done. However, they can get in the way of people and their interactions. This is when we now value the left side of the manifesto. Processes and tools stifle creativity. They encourage individuals to conform rather than bring on board new ideas, or new requirements. However, when we value individuals and interaction more, we encourage innovation and problem solving.
…read full post
In the traditional approach (called Waterfall) most developers never feel the owner of the code.
Why did this situation happen?
Because they haven’t any opinion about the technical issues related with the requirements. Business Analysts think and write uses cases (or other form to specify the requirements) to document each requirement. Then architects move all this information to technical level such as model of database and so on. Even more, there were some company (or maybe there are still companies working in this old way) that provide a framework to developers in order to standardized the development.
…read full post
Scrum is a simple and flexible software development methodology or framework. Scrum framework introduces alternatives to traditional project management systems such as Waterfall or Sequential development. In scrum we only have three roles; product owner who represents the clients or users, the scrum master who is the silent leader and the team.
From my experience, additional roles are not needed since they don’t usually bring extra benefits. The Scrum framework covers all the necessary aspects for successful software and product development. Instead of additional roles it is possible to have a product owner team, where the different product owners cover different areas of the product. Depending on the degree of innovation and uncertainty in your project, this might be even necessary since one product owner alone might be overloaded with covering product backlog, user test or constraints for example. …read full post