i want to start a discussion on agile planning. i wish it will never end here ;)
i had experience using deterministic old-school approached (like MS Project's Gantt charts) ,which i was keeping in my tool set for quite a long time,
i did task decomposition, resource leveling, resource assignment, milestone definition
this all was useful while i was doing that because it made me think about the project risks, complex dependencies, the team capabilities and other important and critical for project success topics.
but as soon as i published my plans and tried to stick to them - they quickly became obsolete and useless. it appeared i just couldn't predict everything and eventually the projects went a bit different unpredicted direction.
since i've been doing agile i don't have this problem anymore. why? simply because i never stop planning.
the book is not about plans, rather it is about planning.
once you start using user stories as your main requirements media, you will gain even more flexibility in planning and hence obtain more control.over the project. planning will become a solid practice being done by the whole team during the coarse of the project, also user stories will foster idea sharing between product managers and engineers, will provoke creative and positive thinking
> but as soon as i published my plans and tried to stick to them - they > quickly became obsolete and useless. it appeared i just couldn't > predict everything and eventually the projects went a bit different > unpredicted direction.
I think, You did not pay necessary attention to project tracking. And, maybe, You plan in details rather big amount of work (e.g. 2 month). There is a common mistakes - to make a Grand Plan (just as Grand Design) and to try to implement it as one piece. Iterative approach in RUP and MSF excludes such a mistake, when used wisely :) Every short iteration (from week to 2 months) MUST deliver some factual result - version or delivery. All future iterations are planed, but not in detail. And the whole Master Plan is rather flexible. Why? Because we use a Trade-off Matrix. So we fix ONLY one parameter and are free to change another two. This flexibility (when used wisely ;) ) leads to predictable, but not limitative process. Determinative - the best word to describe it :) And, Yes, we must replace micromanagement by shared responsibility and bottom-to-top estimations.
And even with very flexible planning I recommend to define short/small projects when creating big and complex product. E.g. for product with basic estimation of 2 years of implementation and deployment we can state 4 separate projects: Pilot, Main Functions, All Functions and Deployment. Every project with full cycle, including analysis, deployment and hand-over activities. Every project with separate contract and set of documents.
The other mistake which can affect planing is collaboration of PM in development as Architect or Developer. Did it occur?
> And even with very flexible planning I recommend to define short/small > projects when creating big and complex product. E.g. for product with > basic estimation of 2 years of implementation and deployment we can > state 4 separate projects: Pilot, Main Functions, All Functions and > Deployment. Every project with full cycle, including analysis, > deployment and hand-over activities. Every project with separate > contract and set of documents.
i'd call them releases and of course each release should include the full cycle, but i go more - i say that all iterations should include the full cycle as much as possible. that's the idea of sashimi concept used by Ken when he explains Scrum.
the idea is that each slice of the meal (read: each iteration, each Scrum sprint) is totally complete (read: done 100%) and can be eaten (read: deployed) separately
> The other mistake which can affect planing is collaboration of PM in > development as Architect or Developer. Did it occur?
didn't get this point, could you please explain in more details?
> i'd call them releases > and of course each release should include the full cycle, > but i go more - i say that all iterations should include the full > cycle as much as possible. > that's the idea of sashimi concept used by Ken when he explains Scrum.
No. This is not the same as a completely new project with own Contract and goals. Yes. Every iteration must include whole cycle (all phases of MSF, e.g.) and finish with release. But not the hand-over - agreement with customer that project is finished and it's goal is achieved.
> > The other mistake which can affect planing is collaboration of PM in > > development as Architect or Developer. Did it occur?
> didn't get this point, could you please explain in more details?
In MSF exists firm recommendation - do not mix Development Role with Program Management Role (which includes project management activities). This mix extremely lowers the quality of project control, planing and source code (e.g. because of poor code review). And it's true, I confirm it.
> In MSF exists firm recommendation - do not mix Development Role with > Program Management Role (which includes project management > activities). This mix extremely lowers the quality of project control, > planing and source code (e.g. because of poor code review). And it's > true, I confirm it.
Hi, Arty The answer depend on what you mean under "Project Manager". Because from what you say it looks like you're mixing the project manager's role and team leaders role. In most of the cases these two roles are suggested separated. As I understand the general recomendation is that Project Manager (Scrum Chicken) never programs (but of course this can chenge). Concerning team leader - he can turn into sort of Scrum Master. In agile methods, the control function of a project leader is reduced to minimum. It's the team who does most part of the control. He spends 15 min a day for daily stand up + 15 min for maintaining backlogs. I think that the rest if the day can be spent (and is recommended) for programming.
From my personal experience - I have tried mixing up development and management roles and indeed the quality control over the project as well as my development success were very poor. There is only one but. If to be honest with ourselves we used the waterfal development process with top-to bottom management. Another interesting aspect was that the customers are geographically away from the development team and I had to do most of the communication stuff with the customers and from cycle to cycle I had to shift my programming tasks.
So indeed if it's not agile and you have more functions that just a Team Leader - it's better to reduce the amount of programming.
> > In MSF exists firm recommendation - do not mix Development Role with > > Program Management Role (which includes project management > > activities). This mix extremely lowers the quality of project control, > > planing and source code (e.g. because of poor code review). And it's > > true, I confirm it.
> Hi, Arty > The answer depend on what you mean under "Project Manager". Because from > what you say it looks like you're mixing the project manager's role and team > leaders role. > In most of the cases these two roles are suggested separated. As I > understand the general recomendation is that Project Manager (Scrum Chicken) > never programs (but of course this can chenge). Concerning team leader - he > can turn into sort of Scrum Master. In agile methods, the control function > of a project leader is reduced to minimum. It's the team who does most part > of the control. He spends 15 min a day for daily stand up + 15 min for > maintaining backlogs. I think that the rest if the day can be spent (and is > recommended) for programming.
> From my personal experience - I have tried mixing up development and > management roles and indeed the quality control over the project as well as > my development success were very poor. There is only one but. If to be > honest with ourselves we used the waterfal development process with top-to > bottom management. > Another interesting aspect was that the customers are geographically away > from the development team and I had to do most of the communication stuff > with the customers and from cycle to cycle I had to shift my programming > tasks.
> So indeed if it's not agile and you have more functions that just a Team > Leader - it's better to reduce the amount of programming.
> One thing to also remember, there is no "Project Manager" role within > Scrum. This is done for a reason (smile).
> - mike
> On 2/23/07, Roman Muntyanu <muntyanu.ro...@gmail.com> wrote:
> > > In MSF exists firm recommendation - do not mix Development Role with > > > Program Management Role (which includes project management > > > activities). This mix extremely lowers the quality of project control, > > > planing and source code (e.g. because of poor code review). And it's > > > true, I confirm it.
> > Hi, Arty > > The answer depend on what you mean under "Project Manager". Because from > > what you say it looks like you're mixing the project manager's role and team > > leaders role. > > In most of the cases these two roles are suggested separated. As I > > understand the general recomendation is that Project Manager (Scrum Chicken) > > never programs (but of course this can chenge). Concerning team leader - he > > can turn into sort of Scrum Master. In agile methods, the control function > > of a project leader is reduced to minimum. It's the team who does most part > > of the control. He spends 15 min a day for daily stand up + 15 min for > > maintaining backlogs. I think that the rest if the day can be spent (and is > > recommended) for programming.
> > From my personal experience - I have tried mixing up development and > > management roles and indeed the quality control over the project as well as > > my development success were very poor. There is only one but. If to be > > honest with ourselves we used the waterfal development process with top-to > > bottom management. > > Another interesting aspect was that the customers are geographically away > > from the development team and I had to do most of the communication stuff > > with the customers and from cycle to cycle I had to shift my programming > > tasks.
> > So indeed if it's not agile and you have more functions that just a Team > > Leader - it's better to reduce the amount of programming.
Hmmm... seems like a good topic for me to cover in a comic strip next week :).
It is fun (and rewarding for all) to see the evolution of a team from specialists (I am a tester, I am an architect, etc.) to "I am a member of X team."
- mike
On 2/23/07, Roman Muntyanu <muntyanu.ro...@gmail.com> wrote:
actually there are not so many roles: ScrumMaster, ProductOwner, team member(s) and somebody(ies), who is interessted in this product (or something like this).
If we think, there can be project manager - so which roles, which respossibilities does she has? If "to order a pizza" for team members, so I would like to see such "role" in our team :)
