Agile product development for Startups – Part one – First steps

Agile Product Development

So you think you have a brilliant idea that will become a hugely successful product or service. Congratulations!

But how do you turn that idea into a well considered, structured game plan for how you will turn your concept into reality?

Traditionally, you’d do a bunch of stuff around market research, business plans, big project plans and a whole heap of things before you get anywhere near building the thing. But you’re an Agile startup right?

In these short posts, I’ll be referring to the great work of Roman Pichler. I consider Roman to be at the top of the tree when it comes to Agile Product Management specialists. His site has loads of detailed background and resources on the areas I will just skim over.

So how do you quickly get from a concept to an initial Product Backlog you can start working with? Here’s a high level of the first steps you probably want to take.

Step 1 – Understand your users. You should create personas for the different types of user your concept is aimed at. A persona is a fictitious person who represents as closely as possible a typical type of user of your product or service. Personas are important because they remind you that you are developing a product for people, not generic user types like “Author”, “Editor”, “Administrator”, “System User” etc. In most cases, you’ll have multiple personas to represent the different types of people your product is for. Make your personas visible in your team space to remind you everyday whom you are designing for. You don’t have to define loads of detail up front. Your personas will evolve as you learn more about them through user testing and other forms of feedback. Here’s a short definition from the Agile Alliance.

Step 2 – Develop the Product Vision. In short, you need to define who are your users, what of their needs are you going to address, a super high level view of the capabilities your product or service will provide to meet those user needs, and finally, what’s in it for you? You should also define a one sentence “vision statement” to encompass the whole concept. A vision statement for YouTube might be “A free online video hosting, sharing and streaming service funded by advertising”.

The Product Vision is important because it provides scope boundaries. We know that things move in and out of backlogs as we gather insights and inspiration.

We may define a Product Vision for a new car, and as we learn more about our users and our needs, an initial view that they want four seats may change. They may want six seats, because in our target market, people often travel with the whole family. But it’s still a car.

However, if our Product Owner explains that we need to provide 50 more seats, spread over two decks, that’s not a car any more. It’s a bus, and that doesn’t fit within the overall Product Vision.

That’s not a bad thing. It doesn’t mean we say “No, we’re building a car, so we won’t do that”. If our users really need a bus, we should reset the product vision and the steps that follow it. What we have discovered is that the car is not the right product to build.

The Product Vision is also very important to align understanding and expectations early from stakeholders. If you are going out to angel investors or other routes to seed funding, the PV and other artefacts will be absolutely vital to get your concept across concisely and professionally.

Roman Pichler’s Product Vision board is a fantastic resource that I have introduced to many teams. I wholeheartedly recommend it. Here’s a link to Roman’s site.

Once you have your Personas and Product Vision established, you have a solid foundation to work from. The PV is vitally important, but it lacks a critical dimension – time. In my next post, I’ll explain how you build on the Product Vision to move towards creating that Initial Product Backlog.

Advertisements

Five factors that can go wrong with software development

Software development projects

I have been lucky enough to be involved in many software development projects and the best or worst thing about each project is that every project throws you in the deep end with a new challenge. There are many experts, methodologies and tools that promises businesses that projects can be understood and implemented in the desired way without much hassle but very rarely are projects developed smoothly.

Based on my experience as a business analyst and project manager, I have brought together various factors that could constitute a project delivery and noted what could possibly go wrong with these ingredients and, from my limited experience, how can we resolve them!

Even though it might be old cliché all development projects are about people, processes and technology. However, there is always a debate about the weighting of these which factors in order to ensure successful delivery.

People

People or stakeholders are the most critical aspect of any project, and if we believe into experts’ stats, 80% of project success relies on how satisfied people are with the outcome

What can go wrong with stakeholders?
When stakeholders with conflicting objectives are not looked after well, the project can end in disaster!

How can this issue be resolved?
The mantra is to build relationships (via continuous communication with pure honesty and integrity) with each stakeholder to win their trust and understand their objectives. And once you know their goals, it becomes easy to lead from the front and be proactive so that you can tell your stakeholders how you are looking after their interests and create a win-win situation.

Process

Business processes are the heart of any project because these aspects define how businesses works in order to make successful proposition. And all projects are meant to either enhance existing processes or implement a new process in order to improve operation.

What can go wrong with processes?
Too much focus on people and technology can cause business process ignorance. I have seen lots of projects which, after a successful implementation, are scrapped due to their failure to implement the right processes.

And Solution is…
My experience is that the best way to ensure that processes are implemented correctly is to conduct a thorough analysis so that the precise scope can be defined and aligned to businesses. Strong leadership is then necessary to ensure successful implementation.

Technology

Technology helps companies to implement processes and let users operate their business.

What could go wrong with technology?
Over the, last decade or so we have seen great advances in technology that have led to us being carried away with the wonders it can do when it comes to project implementation, and that’s where things go wrong, be cause technology might force stakeholders to compromise on their objectives and can led to a non- business- relevant project i.e. either a project which is too advanced for the end user or not really implementing the right process.

How can this issue be resolved?
A Simple one liner is that the best way is for the business to lead on what technology should do, and not the other way round.

There are two more additional factors that can lead a project’s failure.

Development Methodologies

Two types of project development methodologies (Agile and Waterfall) are very prevalent in project management. They help to define various stages of the project and how to manage them.
But the problem is that sometimes, I have seen that the PMs and BAs get so obsessed with methodologies and their artifacts that they deviate from the main business objectives and deliverable, and that leads to delays or scope creep.
How can this issue be resolved?
Projects that adopt these methodologies loosely in order to put more emphasis on deliverables become more successful than those that wrangles between tightly- coupled methodologies and artifacts.

Development tools

To implement the above methodologies, there are many tools out there that already have templates in place to create everything from project plans to project initiation documents and requirements capturing documents, but .
again the issues is that PMAs and BAs gets too fixated with these tools and forget about real project deliverables, focusing more on tools.

We should limit the use of these tools and methodologies to ensure smooth project delivery, rather than putting in masses of time and effort to than mastering the tools.

Conclusion

No project can be delivered successfully until, as PM and BA, you have a grip on stakeholder objectives and, project scope, and then an understanding of technology to ensure that process are implemented as per business requirement., However, don’t forget no project will be implemented entirely without hassle, and the old saying is that every project has three phases: “storming, norming and performing” – I leave it to your imagination to interpretate what this means!!