Dear reader,
This is the third and last part of “How to reach deadlines”. This is possibly the simplest part and it might be that I am kicking in open doors for many of you. But I am going to write about it anyway.
To be able to be fully flexible on your product scope it is best to work with agile development. If you have developed your product starting from the showstoppers going down the product backlog to the "good to have" stuff, you are in a quite good position to decide when to stop adding new functionality. Many times we think that a functionality is a showstopper, but I am sure that it might not be if you think really hard about it...So be smart and de-scope things that you surely can live without and add them as an upgrade later. Even fundamental things that have been on your showstopper list might not be a showstopper.
For example, with the very much hyped iPhone, I am quite sure that they wanted to have multitasking even in the first release. But they probably ran low on memory when opening too many applications, which creates the feeling of a slow UI etc. They simply had to make a decision not to include the multitasking; to be able to release the product with as good quality as possible. Many people have of course criticized Apple for not having multitasking, but they are selling like no one else, so I think Apple is not too sorry about it. In my opinion it was a very very wise decision and I know another company that might had been more successful today if they would have made the same type of decisions in 2005/06.
So the point is, always look at the scope first and be creative, the showstoppers you think you have might not be showstoppers and never compromise on time and quality.
Best regards
Anders
Showing posts with label Development Process. Show all posts
Showing posts with label Development Process. Show all posts
Tuesday, 11 May 2010
Saturday, 6 March 2010
The development process part 3!
Dear reader,
In the first 2 post on the development process I have written about the business process and project execution model. But before I talk about the feedback loop process which is the 3rd part of a successful product development process, I just want to also finalize with some comments on the 3rd part of the project execution model the maintenance phase. Basically the maintenance phase is more or less a copy of the before execution phase and the execution phase but often in a much less or strict form. It can often be run with only two light wight business decision and using Scrum as execution model on the existing product backlog.
Okay now back to the feedback loop process. It is part of a very important part of the so called learning organization. As I stared of with in my first post I have yet to see any organization that know 100% what they are doing and a common mistake is that most organization does not learn from the mistakes or even from the good things they do. Or as George Bernard Shaw put it in one of my favorite quotes: “We learn from history that we learn nothing from history”.
Also since many organizations often are on the level 1 of the CMMI-model they trust heroes in there organization to fix the big issues and come through in the end, however sometimes these heroes leave your company and then you need a process that anyone can use and repeat the success of the last time and a process that is world class. Therefore you need a working feedback loop process.
So, how do you setup a working feedback loop process. First to be able feedback things back to something you need process and other frameworks in place to start with. The process and frameworks you need are the following:
Now if you have the above, very good! You can now start using a controlled feedback loop process and become a learning organization (if not you have some work todo :- ). So how does the feedback loop work. You should introduce in your product development checklists that the project should have lessons learned sessions on a regular basis and also use the part in Scrum that is used after every sprint that is called a Sprint retrospective. These two tools and on the softer side work on a company culture that want to improve productivity hence feedback improvements continuously.
The trick then is to get your employees to feedback lessons learned sessions and sprint retrospective feedback to you or any manager within the company that might need to have the feedback and in 95% of all cases you as manager can feedback this data into any of the above 3 things (i.e. checklists, roles and responsibilities or your process). And voila, you have feedback loop process and have become a learning organization. Sounds easy? Yes but it is not so easy in reality, there are many pot holes you might fall into. For example do not implement a huge database where you store all lesson learned and hope that people would be able to ready it all…It will not work you will be overwhelmed with data. Keep it simple and try to feedback and upgrade process, checklist and roles and responsibilities on a regule basis so these documents become living document, then you also have a much bigger chance that you will get your employees to read them more often.
Have a nice weekend!
Anders
In the first 2 post on the development process I have written about the business process and project execution model. But before I talk about the feedback loop process which is the 3rd part of a successful product development process, I just want to also finalize with some comments on the 3rd part of the project execution model the maintenance phase. Basically the maintenance phase is more or less a copy of the before execution phase and the execution phase but often in a much less or strict form. It can often be run with only two light wight business decision and using Scrum as execution model on the existing product backlog.
Okay now back to the feedback loop process. It is part of a very important part of the so called learning organization. As I stared of with in my first post I have yet to see any organization that know 100% what they are doing and a common mistake is that most organization does not learn from the mistakes or even from the good things they do. Or as George Bernard Shaw put it in one of my favorite quotes: “We learn from history that we learn nothing from history”.
Also since many organizations often are on the level 1 of the CMMI-model they trust heroes in there organization to fix the big issues and come through in the end, however sometimes these heroes leave your company and then you need a process that anyone can use and repeat the success of the last time and a process that is world class. Therefore you need a working feedback loop process.
So, how do you setup a working feedback loop process. First to be able feedback things back to something you need process and other frameworks in place to start with. The process and frameworks you need are the following:
- Process for all part of the company: Sales & Marketing, development, support, operations etc…
- Product development checklists for product managers, project managers and developers to have as support tools when developing new products.
- Written down clear roles and responsibilities
Now if you have the above, very good! You can now start using a controlled feedback loop process and become a learning organization (if not you have some work todo :- ). So how does the feedback loop work. You should introduce in your product development checklists that the project should have lessons learned sessions on a regular basis and also use the part in Scrum that is used after every sprint that is called a Sprint retrospective. These two tools and on the softer side work on a company culture that want to improve productivity hence feedback improvements continuously.
The trick then is to get your employees to feedback lessons learned sessions and sprint retrospective feedback to you or any manager within the company that might need to have the feedback and in 95% of all cases you as manager can feedback this data into any of the above 3 things (i.e. checklists, roles and responsibilities or your process). And voila, you have feedback loop process and have become a learning organization. Sounds easy? Yes but it is not so easy in reality, there are many pot holes you might fall into. For example do not implement a huge database where you store all lesson learned and hope that people would be able to ready it all…It will not work you will be overwhelmed with data. Keep it simple and try to feedback and upgrade process, checklist and roles and responsibilities on a regule basis so these documents become living document, then you also have a much bigger chance that you will get your employees to read them more often.
Have a nice weekend!
Anders
Thursday, 4 March 2010
The development process part 2!
Dear reader,
Yesterday I wrote about the top level of the product development process, today I am going to focus on the project execution model. This part is the core part of the product development process but I will not work without the business process.
The project execution model is divided in 3 parts as well.
In the before phase is where you decided what kind of product you would like to develop. Agile purist might say that that 1 and 2 should be one and that you can start with just a few user stories and from that build the product sprint by sprint. However I have yet to see any product being built like that. Even if you are very agile, product management need to have a vision for the product already from the start and product management probably have to have a business case and wanted delivery date etc. If not top management will not spend any money on the project. So most of the time you must have most of the framwork for the product given, a maximum budget and a delivery date even before your start any of the project execution. If we agree on this, then you need to do no 1 as a pre-study and possible a deeper design an system analysis (even if you are very agile) to be able to at least set an optimal system architecture, high level requirements estimates etc. When you have your top level requirements stack ranked and guesstimated the effort i.e. the product backlog (see my other blog post on how to do the stack ranking with for example focal point), you now have a good top down view of the overall project.
Now you have an high level time guesstimated and a wanted delivery date, a budget and a product backlog (i.e. your system requierments). Now it is time for the business decision on the top level business process to make a decision on the possible bright or dark future for the product. If it is a bright future it is time to start the execution phase (2) using for example an agile method like Scrum. I think Scrum is very good to use for the execution phase of most SW development projects (more indepth evaluation of Scrum and best practice in a later blog post).
In my opinion an agile project should only be agile in two parts or maybe only one (it depends on how much money you have :-). But normally you should only be agile on the requirements because the delivery date, the quality and resources /cost should or is almost always fixed. Now execute your project sprint by sprint to reach your targets.
If you have a very mature organization with a good test organization and test cases, daily builds etc. You might be mature enough to release your product after the last sprint, if not always plan the last sprint with new features as a beta release and try to learn how many/long you stabilization sprints should be.
I use this mix of a business and execution model since no one model often give you all what you need. This way of working is a mix of the waterfall model and the agile project execution model.
This is it for today…
Kind regards
Anders
Yesterday I wrote about the top level of the product development process, today I am going to focus on the project execution model. This part is the core part of the product development process but I will not work without the business process.
The project execution model is divided in 3 parts as well.
- The before execution phase
- The execution phase
- and the maintenance phase
In the before phase is where you decided what kind of product you would like to develop. Agile purist might say that that 1 and 2 should be one and that you can start with just a few user stories and from that build the product sprint by sprint. However I have yet to see any product being built like that. Even if you are very agile, product management need to have a vision for the product already from the start and product management probably have to have a business case and wanted delivery date etc. If not top management will not spend any money on the project. So most of the time you must have most of the framwork for the product given, a maximum budget and a delivery date even before your start any of the project execution. If we agree on this, then you need to do no 1 as a pre-study and possible a deeper design an system analysis (even if you are very agile) to be able to at least set an optimal system architecture, high level requirements estimates etc. When you have your top level requirements stack ranked and guesstimated the effort i.e. the product backlog (see my other blog post on how to do the stack ranking with for example focal point), you now have a good top down view of the overall project.
Now you have an high level time guesstimated and a wanted delivery date, a budget and a product backlog (i.e. your system requierments). Now it is time for the business decision on the top level business process to make a decision on the possible bright or dark future for the product. If it is a bright future it is time to start the execution phase (2) using for example an agile method like Scrum. I think Scrum is very good to use for the execution phase of most SW development projects (more indepth evaluation of Scrum and best practice in a later blog post).
In my opinion an agile project should only be agile in two parts or maybe only one (it depends on how much money you have :-). But normally you should only be agile on the requirements because the delivery date, the quality and resources /cost should or is almost always fixed. Now execute your project sprint by sprint to reach your targets.
If you have a very mature organization with a good test organization and test cases, daily builds etc. You might be mature enough to release your product after the last sprint, if not always plan the last sprint with new features as a beta release and try to learn how many/long you stabilization sprints should be.
I use this mix of a business and execution model since no one model often give you all what you need. This way of working is a mix of the waterfall model and the agile project execution model.
This is it for today…
Kind regards
Anders
Wednesday, 3 March 2010
The development process part 1!
Dear reader,
A working product development process is very important to have if you want to be successful delivering product within time, budget and with the right quality. Your process needs to be more or less tailor-made for your own organization, however I will write about some very important building blocks today and in the coming weeks try to give more details into all building blocks. The process must consist of at least 3 parts:
Why an overall business process?
Today every one talks about using scrum and being agile. However it is not enough to just send a few people to a Scrum Master course and tell your developers to work with scrum. I really like scrum and it is a very good execution methodology but it does not really support the business side of things. Hence you also need to provide a business tollgate process on top of your project execution model to make sure you use the companies development resources in the best way producing customer and business value. I see the need for a minimum of 4 business tollgates.
Each business tollgates need to have in-put from product management on the business case and market, from development on resources, quality and project status etc.
This process should be supported by a steering group with the right management people attending for decisions. In a company smaller than 200-300 people it can often be the companies normal management team + the head of projects / program management.
More about the project execution model soon….
Kind regards
Anders
A working product development process is very important to have if you want to be successful delivering product within time, budget and with the right quality. Your process needs to be more or less tailor-made for your own organization, however I will write about some very important building blocks today and in the coming weeks try to give more details into all building blocks. The process must consist of at least 3 parts:
- An overall business process (with business tollgates)
- A project execution model with: milestones, execution methodology (possibly an agile model), checklists, etc.
- A feedback loop process to always improve the above
Why an overall business process?
Today every one talks about using scrum and being agile. However it is not enough to just send a few people to a Scrum Master course and tell your developers to work with scrum. I really like scrum and it is a very good execution methodology but it does not really support the business side of things. Hence you also need to provide a business tollgate process on top of your project execution model to make sure you use the companies development resources in the best way producing customer and business value. I see the need for a minimum of 4 business tollgates.
- To start a pre-study/design phase
- To start execution
- Release of the products to customers
- Ending the products life
Each business tollgates need to have in-put from product management on the business case and market, from development on resources, quality and project status etc.
This process should be supported by a steering group with the right management people attending for decisions. In a company smaller than 200-300 people it can often be the companies normal management team + the head of projects / program management.
More about the project execution model soon….
Kind regards
Anders
Monday, 1 March 2010
So how do I make sure I get the right requirements for a product?
Dear reader,
Of course it is not the R&D/development department that actually should go about and collect the requirements for the product. It should be the product manager (or product planner) that collects the requirement on a high level. Often the product manager listens and talks to the customers and follows the latest technical trends and so forth. There are seldom any issues in these areas if you have a good product manager you will normally have the right requirements in these areas (however a bad product manager can kill any product). The difficult parts are often the non functional requirements, usability or requirements on perceived quality or performance. To get these requirements right you might need to push the CEO or head of product management in the management team to improve the requirements gathering process to include the right stakeholders. Stake holders that are typically not included are operations (including the installation team), usability experts, executive management (to make sure you get early feedback, otherwise you might have to make changes later) and customer support.
Now! When the product manager have collect the “right” requirements your system design department and chef architect should add all technical requirements that are needed in the pluming to fulfil all top level requirements and start a pre-study (more on the process when to start new pre-studies in later posts) to quickly assess the work effort for each work item on a top level. In the meantime the product manager need to start ranking the requirements 1-n. If you have a very big number of requirements you need some kind of tool to help you prioritizing the requirements. I recommend the product manager to use IBM Focal Point (IBM® Rational® Focal Point™). If you have a very big number of requirements you should make three piles:
(Please note: if you have less requirements you can just use a Scrum type product backlog to have control over all your requirements.)
However if you using the 1, 2, 3 approach above you do this because you have a limited budget or resources and a fixed wanted delivery date for you product. In most cases you can forget about the 3 in the first release of the product so it is all about doing a focal point on number 2 and get all the most important requirements from this group into the product within you budget. Ready more about Focal point here: http://www-01.ibm.com/software/awdtools/focalpoint/
In the end, independently what type of tool you use, in my opinion you need to have a long list of the requirements that are individually ranked from 1-n, no. 1 being the most important requirement and 2 the second most important requirement etc (i.e. the same way you do a product backlog when using Scrum). Why? Because when you use for example groups of priority 1, 2 and 3 that many companies do, you often end-up not thinking the requirement through 100% and you do not get the right grouping in your incremental development when it starts. When the above is done you should now have a product backlog and the requirement part of the pre-study for the product should be ready for the next step: The detailed design and analysis phase.
Kind regards
Anders
Of course it is not the R&D/development department that actually should go about and collect the requirements for the product. It should be the product manager (or product planner) that collects the requirement on a high level. Often the product manager listens and talks to the customers and follows the latest technical trends and so forth. There are seldom any issues in these areas if you have a good product manager you will normally have the right requirements in these areas (however a bad product manager can kill any product). The difficult parts are often the non functional requirements, usability or requirements on perceived quality or performance. To get these requirements right you might need to push the CEO or head of product management in the management team to improve the requirements gathering process to include the right stakeholders. Stake holders that are typically not included are operations (including the installation team), usability experts, executive management (to make sure you get early feedback, otherwise you might have to make changes later) and customer support.
Now! When the product manager have collect the “right” requirements your system design department and chef architect should add all technical requirements that are needed in the pluming to fulfil all top level requirements and start a pre-study (more on the process when to start new pre-studies in later posts) to quickly assess the work effort for each work item on a top level. In the meantime the product manager need to start ranking the requirements 1-n. If you have a very big number of requirements you need some kind of tool to help you prioritizing the requirements. I recommend the product manager to use IBM Focal Point (IBM® Rational® Focal Point™). If you have a very big number of requirements you should make three piles:
- These are all must have (i.e. without these there is no product)
- These are the requirement that will give your product an edge, but you could live without them if you must
- These are good to have stuff
(Please note: if you have less requirements you can just use a Scrum type product backlog to have control over all your requirements.)
However if you using the 1, 2, 3 approach above you do this because you have a limited budget or resources and a fixed wanted delivery date for you product. In most cases you can forget about the 3 in the first release of the product so it is all about doing a focal point on number 2 and get all the most important requirements from this group into the product within you budget. Ready more about Focal point here: http://www-01.ibm.com/software/awdtools/focalpoint/
In the end, independently what type of tool you use, in my opinion you need to have a long list of the requirements that are individually ranked from 1-n, no. 1 being the most important requirement and 2 the second most important requirement etc (i.e. the same way you do a product backlog when using Scrum). Why? Because when you use for example groups of priority 1, 2 and 3 that many companies do, you often end-up not thinking the requirement through 100% and you do not get the right grouping in your incremental development when it starts. When the above is done you should now have a product backlog and the requirement part of the pre-study for the product should be ready for the next step: The detailed design and analysis phase.
Kind regards
Anders
Subscribe to:
Posts (Atom)
Posts
