agile planning

[Alexey Krivitsky]

hi all

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.

i highly recommend Mike Cohn's masterpiece "Agile Estimations and Planning"
(http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415/sr=8-1/qid=1172098850/ref=pd_bbs_sr_1/103-9473446-0931802?ie=UTF8&s=books)

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

// alexey
// www.krivitsky.com

[ArtyRak]

> 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?

[Alexey Krivitsky]

> 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.

http://en.wikipedia.org/wiki/Sashimi

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?

[ArtyRak]

> 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.

[Roman Muntyanu]

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.

 

Regards,

 Roman

 

[Michael Vizdos]

Hi all...

One thing to also remember, there is no "Project Manager" role within
Scrum. This is done for a reason (smile).

- mike

[Alexey Krivitsky]

... and I also vote for rotating ScrumMaster to avoid just renaming of
a "Project Mananer" title into a "ScrumMaster" w/o any changes in the
minds

[Roman Muntyanu]

Hi all...

One thing to also remember, there is no "Project Manager" role within
Scrum.  This is done for a reason (smile).

Who is the chicken then? %)

 

[Alexey Krivitsky]

Roman,

pigs are the team members
ScrumMaster is a facilitator (also a pig probably)

all other interested people are just chickens

do you know why it is so?

On 2/23/07, Roman Muntyanu <muntyan...@gmail.com> wrote:
>

[Roman Muntyanu]

Yes :)

 http://www.implementingscrum.com/cartoons/implementingscrum-20060911.html

but somehow I thought that project manager is a chicken :)

By the way, maybe it's worth opening a new discussion - to explain roles in Agile process.
 

[Michael Vizdos]

So in Scrum there are only three roles....

Scrum Master
Product Owner
Team Member.

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

[Max Pendyschtschuk]

Hi, Roman :)

 

> to explain roles in Agile process.

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 :)

 

regards.

Roman Muntyanu <muntyan...@gmail.com> schrieb:

Yes :)

 http://www.implementingscrum.com/cartoons/implementingscrum-20060911.html

but somehow I thought that project manager is a chicken :)

By the way, maybe it's worth opening a new discussion - to explain roles in Agile process.
 

---

Yahoo! 360° – Bloggen und Leute treffen. Erstellen Sie jetzt Ihre eigene Seite – kostenlos!.