Change Management, etc.€¦ · subprocess managers, quality engineers, etc. February 15th, 2005...

Change Management, [email protected]

February 15th, 2005 Page 2

Good project manager

• Read Maria’s slides on Managing teams and think if you really do that.• If you think trying to actively build a “jelled team” is a bunch nonsense,

think again.• Business Rules of Acquisition #36 (Towo Toivola & Jukka Talvio): “In a

world where everyone's main goal is the pursuit of happiness, you can't afford to ignore feelings.”

• One more thing: The team must participate in the decisions. Project Manager is not necessarily the one telling what to do. She has the responsibility and therefore must have the authority, but to make a team good, everyone must participate.

• Read Tom DeMarco and Tim Lister’s Peopleware. Everyone in software industry should read it.


Quality

Is hard to measure using these methods• Bug count• Against specification and/or requirements• Customers’ needs• Customers written requirements• Conformance to standard

Is not hard to measure• Just ask the customer.


Quality is a tool for making profit

Quality == Happy customer == Revenue


Silver bullet of software development, if there is one.

Customer involvement

Frequent deliveries of intermediate productsto customers.

Changing the project based on customerfeedback.


My opinion on IEEE standards

Intended for 50 billion $ projects for getting a man to take a few steps on the moon.And even then, there is a more efficient way.


At the end of the project, Lessons Learned

Mistakes are done during the project

Lessons must be learned during the project


Target of Project: General AvailabilityGoal

• Get a commercially successful product into general availability.Product

• Meets the ”FURPSS” requirements F-Secure and Partners

• Ready to market & sell• Ready to handle orders & deliver• Ready to support & train

Customer • Is satisfied with the product and services• Buys the product and services

The project manager is responsible to ensure that all this is in place when the product is in General Availability.

GeneralAvailability

R1S1 V3 V1V2

Release

D1S2

SystemTest

BetaValidation

RCValidationDevelopment Iterations

GAScreening Validation

DA Dn ... D2

Development

Business and FeasibilityStudy

Product &Project

Initiation

Product &Project

ElaborationReleasing


F-Secure Product Realization Process Sub Processes

Fix Realization Process

Testing

Software EngineeringLocalization

Partner, Sales and Customer Training

Support realization


What is a product?

It is called F-Secure Product Realization process

What all items we need to have before we can have a commerciallysuccessful product?


F-Secure Product includes at least sometimes

• Software

• Support

• Manuals

• License agreement

• Package

• eStore

• (PC Super) Store stands, material

• F-Secure sales training

• Sales Channel Training

• Web pages

• Marketing material

• Sales guides

• Development documentation

• Manufacturing and logistics processes

• AV database services

• Virus web pages

• Localization of necessary material


Milestones and workflowsW orkflow /A ctivity

R equirem ents

In tensity o f w orkflow s during typ ical pro ject

Screening and In itia tion D evelopm ent V alidation R eleas ing

Business s tudy

M arketing and C om m s

Project M anagem ent

D esign and C oding

Testing

D ocum entation

Localization

Technica l T ra in ing

Extenal V alidation

S ales T ra in ing

D 1(A lfa1)

R 1(G A)

S1(G o) D 3(A lfa 3)

V3(B eta)

V1(R TM )V 2(R C )

S2(P lan)

R 2(FC S )

S 3(S tudy)

D 2(A lfa 2)

S ponsoring andP roduct D ecis ions

S 4(Idea)

M anufacturing andLogis tics

B uild M astering


Project Management

Product Council makes the investment decisions

Project Steering Group (PSG) is the highest authority in a project within the scope agreed in Product Council.

Project Manager (PjM)

Project Manager may form a Project Management Team from the subprocess managers, quality engineers, etc.


Development IterationsGeneral

Availability

R1S1 V3 V1V2

Release

D1S2

SystemTest

BetaValidation



DA Dn ... D2

Development


Product &Project

Initiation

Product &Project


Elaboration

Design

Implementation

1 iteration

Test andstabilize

Incremental development of software and services

Project Steering Group defines Dn gate criteria bases on checklists.

The product under development should at all times be stable


Yes, yes, but what about change management

• What the heck is change management?

• Business Rules of Acquisition #67 (Towo Toivola & Jukka Talvio): “The more accurately you plan, the further ahead, the more you will be disappointed.”

Change items•Schedule•Scope•Requirements•Code•Bugs•Enhancements•External / Internal modules, libraries

•User Interface•User documentation•Packaging•License agreement•Etc.


Change Management in F-Secure projects

• Product Council approves project scope, costs, theme, milestone, schedule in S1 gate meeting.

• Scope change > 15% must be escalated back to Product Council. In practice, we use common sense.

• Any Schedule change that moves the final project deadline must be escalated to Product Council. Again, we use common sense.

• Project Steering group has a lot of power to change items in the project.

• Requirements are not officially frozen, nor is anything else, really.

• Change Control Board decides individual changes to once made features. Fast and formal meetings.

• Bugs found by someone other than the developer are entered into a change management tool = bug database.

• After D1 gate, no code change is allowed without a change tracking entry.

GeneralAvailability

R1S1 V3 V1V2

Release

D1S2

SystemTest

BetaValidation



DA Dn ... D2

Development


Product &Project

Initiation

Product &Project



The challenge of Configuration Management

Componenent AComponenent A

Componenent A

1.0

1.1

1.2

2.0

1.0



1.0

1.1

1.2

2.0

Componenent A



1.0

1.1

1.2

2.0

Componenent B Componenent C

1.01.0

1.0

Module X

1.0


Componenent A

1.0

1.1

1.2

2.0

1.0

Higher levelModule Z

1.0


Componenent A

1.0

1.1

1.2

2.0

1.0

Module Y

1.0

Higher levelModule ZF

3.0

Sub product S 2.4 build 236


Changing code and architecture: refactoring

Slide: Maaret Pyhäjärvi, Senior Quality Engineer, F-Secure

Continuous modification makes software structure more complex, unless effort is made to reduce this complexity

Refactoring aims at improving software structure without changing the observable behavior

Prime target of refactoring is to improve the design of existing code • 72 refactorings are described (Fowler 2000)

If you want to refactor, the essential precondition is having solid tests – Fowler. Refactoring. 1999


Don’t be afraid of change, embrace it

You must have techniques in use to enable change, not prevent it.

BUT if you are not prepared for change and then you must, be very afraid.

Rule of thumb: You cannot refactor unless you do unit testing.

Ronald E. Jeffries: eXtreme Testing. STQE Magazine, March/April 1999

• ”That was when we knew that extreme testing was magic: we had fearlessly changed an essential assumption of the system, well into development, and in a week, we were certain that it had worked!”


The big thing: changing requirements

• Change Management often means managing changes to requirements.

• Classical: avoid change. Make change so difficult it does not happen.

• Side effect: changes are made unofficially. Sales talks to developers directly, etc.

• At F-Secure, we are too busy to make extra features or enhancements.

• Because change often requires more work, there is healthy culture of wanting to prioritize changes based on business value.

• Product Council approves “feature buckets” or “high level requirements”

• Project Steering Group and Project Management team decides on details.

• Generic solution: Prioritize all the time. Do what is important and ignore the rest.


Major roles

• Product Council: all function heads or their representatives. Executive Team members. Whoever is needed to make sensible business decisions.

• Project Steering Group: Product Manager, Project Manager, Software Architect, Chief Quality Engineer, Customer Advocacy (Support) Representative.

• Other roles: Product Owner, Software Engineer, Quality Engineer, Localization Coordinator, Technical Writer, GUI developers, Release Team, Virus researchers, team managers, Program Managers, Research Engineers, Director Processes & Tools, System Developer, Forum leaders, Build master

Now, something completely different


Plan-Driven vs. Agile - Rationale


A - Start B – Planned Result

C – Desired ResultIn an extreme environment,

following a plan produced the product you intended, not the

product you needed.


Plan-Driven and Agility - ValuesSource: Agile Alliance website


Agile ValuesPlan-driven Values

Processes and tools

Comprehensive documentation

Following a plan

Individuals and interactions

Working software

Customer collaborationContract negotiation

Responding to change


Plan-Driven vs. Agile MethodsSlide: Maaret Pyhäjärvi, Senior Quality Engineer, F-Secure

Agile

Complex and unanticipated processes

Results as the center of the project

Changes can’t and shouldn’t be avoided.

Nature of software development includes continuous learning.

• Learning changes the plan

Plan-driven

Well-understood, repeatable processes

Plan as the center of the project

Plan is made to achieve goals (requirements)

Follow-up on:• Progress

• Deviations from planned

Corrective actions brings one back to the planned state

Often compared heavy vs. light and formal vs. informal– these miss the main difference!

Often compared heavy vs. light and formal vs. informal– these miss the main difference!


Example: Daily Scrum meeting

• 15 minute meeting

• 3 items for discussion:

• What was accomplished since the last meeting

• What the team is going to do before the next meeting

• What obstacles were/are in the way

• Project manager (Scrum master) records and removes the obstacles

• Meetings must be short. Scrum Master must be able to tell Jorma Ollila to speak briefly and not to interrupt others.

• Easier and more efficient than reading a report

• Project manager sees quickly how the project members are doing.

• Standing encourages brevity.


“Forget pert charts”

“…why the industry was in such trouble and had such a poor reputation. We were wasting our time trying to control our work by thinking we had an assembly line …”


Questions

• Ohjelmistoprojekteille, toisin kuin esimerkiksi rakennusprojekteille, on enemmänkin sääntö kuin poikkeus, että projektin aikana tapahtuu muutoksia alun määrittelyihin nähden. Voisiko tämä johtua osittain siitä, että ihmiset ovat oppineet tähän ja muutosten mahdollisuutta pidetään itsestään selvänä? Olisiko mahdollista, että myös ohjelmistoprojektit voisivat toimia niin, että ne aluksi määritellään selvästi ja sen jälkeen toteutetaan määrittelyiden perusteella?

• A: Ei olisi.


Questions

• Change management: Is it better to have a very strict and bureaucratic change management policy even if it adds work overhead?

• No• How common it is to implement fast-prototyping in the project during requirements

planning. What are the downsides of fast-prototyping?• It takes time the size of which is difficult to estimate. BUT: Involve customer!!!

• Mitkä ovat muutoksenhallinnan yleisimpiä haasteita ohjelmistoyrityksissä?• Communication, Prioritizing.

• Change Management: How to prepare to changes in the last iterations? • Move them to the next version, or at least next iteration.

• How to cope with many simultaneous changes?• Carefully ☺ Prioritize!!

• What kind of leadership roles the project manager may have? Can he/she take different kind of roles (guiding/coaching/…) for different employees?

• Yes and should too


Questions

• To what extent project manager should take the personal role preferences into account when dividing tasks?

• There is no clear rule• What are the key success factors in change management, both organization-wise

and people-wise?• Communication and prioritizing

• Change management systems on the market. What is the top three at the moment?

• Serena, IBM (Rational), Telelogic, Borland• Jos työskennellään pienessä ohjelmistoyrityksessä esim. 3 hengen tiimissä niin

mitkä ovat kaikkein tärkeimmät roolit ottaa käyttöön projektissa? • Project Manager, Developer, Chief Quality Engineer

• Do you have a documented change management process in use or is it based on a use of a change management tool ? If you have a tool in use how is it managed (who is responsible, how the approvals are handled/recorded etc.) ?

• Yes, yes, and it would take too long to answer.


Questions

• Miten muutostenhallinta voidaan kytkeä vaatimustenhallintaan?• Managing changes in requirments is one part of change management. Tools

are not as important as agreed working methods.• Millaisia muutostenhallintatyökaluja on olemassa?

• Simple and complex. Expensive and free. Dedicated to one problem area (e.g. bug tracking) or general (Serena’s “solution”).

• Pitääkö projektipäälliköllä olla useita erilaisia rooleja?• Project manager role is diverse enough.Learn to delegate.

• Should change management be implemented in small projects?• Yes but not the same way as in big ones.

• Tell me about the role conflicts. I work currently as a programmer in a large company (started this January) and sometimes I do not agree on methods used by my current project manager or by the decisions made by technical managers. I think I have sometimes made my team mates angry by “telling them how they should do their work”.

• Sounds like conflict between people, not roles.


Questions

• Onko tärkeää saada ihmiset pysymään heille projektin alussa määrätyissärooleissa?

• Depends!• Kuinka työntekijät saadaan käyttämään muutostenhallintaprosesseja niin, etteivät

he vain lisää tuotteeseen keksimiään ”hyödyllisiä” ominaisuuksia kysymättä?• How do you in general get people to do what you want them to do. Not a joke:

Read “How to win friends and influence people.”• Show them consequences in €’s.

• Mikä on paras keino estää hyvin järjestetyn muutostenhallintaprosessin ohituksia ilman, että hallinnasta tulee liian tiukka?

• Make change management simple. Teach the culture.• Mikä muutostenhallinnassa on yleisimmin unohdettu asia, johon erityisesti

ensikertalaiset kompastuvat? • Using a tool does not solve the problem.

• Onko olemassa roolia, joka on haitallinen projektin kannalta? • Probably


Questions• Missä tilanteissa kannattaa turvautua muodolliseen muutostenhallintaprosessiin?

• Bug tracking and requirements management. Formal can also mean “simple and efficient”. In fact, it must.

• Onko projektipäällikön tärkeä tehdä selväksi muille projektiryhmän jäsenille, ettähän on projektipäällikkö, vai voiko tasavertaisempi roolijako toimia?

• Act from the side as much as possible but not more.• Changes are almost inevitable in projects, but are there any skills or any practices

in real companies to minimized changes? If any, what are they? • There is no sense in minimizing changes. Prioritize and agree which ones are

done.• How big can a project group be in order to still be manageable by a single project

manager? • Depends on the project manager and how well she can delegate and how good

people she has in the project.• Kannattaako hattuja vaihtaa projektien välillä ja kierrättää ihmisiä eri tehtävissä?

• Probably• Mikä on tärkein rooli ohjelmistoprojektissa?

• Project Manager


Questions

• Onko tiukka roolijaotus parempi kuin XP-ajattelu, jossa jokainen tekee kaikkea?• No!

• Mikä rooli on projektipäällikölle tärkein?• Project Manager

• How can software project managers balance between administrative and expert roles? Or can it be done at all?

• Delegate• Are there ways control the problems caused by the moving target –problem of

changing requirements?• Yes. Scrum!

• Onko muutosten tekeminen projektiin tehty vaikeaksi osittain siksi, ettei muutoksia tehtäisi?

• Yes!• Onko työntekijöille olemassa jotain taitopistejärjestelmää, jonka avulla heidät

voitaisiin helpommin asettaa oikeaan tehtävään tuntematta henkilöitä sen kummemmin? Miten roolit määrätään?

• I don’t think so.


Questions

• Onko olemassa tutkittua tietoa siitä, millainen roolijako ohjelmistoprojekteissa on todellisuudessa tehokkain?

• I don’t know. Probably not.• Onko ohjelmistoprojekteissa havaittavissa ryhmän organisoinnin ja roolijaon

suhteen jotain selkeästi muista projekteista eriäviä tarpeita? • Yes?

• Miten eri henkilöiden roolit muodostuvat projektitiimeissä? Päättääkö päällikkö ne vai muokkautuvatko ne itsestään projektin edetessä? Ja miten roolien jako vaikuttaa tiimin tuottavuuteen?

• Project Manager is responsible but should not dictate the answer.• Onko roolien jakaminen/vaihtaminen järkevää, vai tulisiko esim. kymmenen hengen

projektissa jokainen tärkeä rooli määrätä yksittäiselle henkilölle? • It depends.

• Do you think that software architects that don’t code can produce successful contributions to a project?

• Often yes and often not.


Questions

• Do you have any experience with projects with a lot of graphics designers and/or other creative artists tightly involved? Are there any special considerations for that kind of a project?

• You mean with people who think they should be allowed to do whatthey want? Yes.

• Suggestion: pick 5 most important rules for the project, communicate them constantly and hold on to them. For instance:

• Weekly planning of tasks with the team, e.g. onto a wall

• Iterations and intermediate releases

• Customer involvement


Questions

• Roles: In small companies with several concurrent projects, what is the most efficient ways of dividing roles among team members? If each project has manager, chief developer (architecture), chief tester (tester in charge), the roles are pretty much overlapped (a manager for this project is a member in another project and vice versa). But if no manager is specified for each project, communication tasks (especially communication with external stakeholders) will become too heavy for a team leader to take.

• Maybe you have too many projects and you should focus.

• Alternatively, you are handling continuous tasks as projects.

Change Management, etc.Good project managerQualityQuality is a tool for making profitSilver bullet of software development, if there is one.My opinion on IEEE standardsAt the end of the project, Lessons LearnedTarget of Project: General AvailabilityF-Secure Product Realization Process Sub ProcessesWhat is a product?F-Secure Product includes at least sometimesMilestones and workflowsProject ManagementDevelopment IterationsYes, yes, but what about change managementChange Management in F-Secure projectsThe challenge of Configuration ManagementChanging code and architecture: refactoringDon’t be afraid of change, embrace itThe big thing: changing requirementsMajor rolesNow, something completely differentPlan-Driven vs. Agile - RationalePlan-Driven and Agility - ValuesSource: Agile Alliance website Plan-Driven vs. Agile MethodsExample: Daily Scrum meetingQuestionsQuestionsQuestionsQuestionsQuestionsQuestionsQuestionsQuestionsQuestionsQuestions

Change Management, etc.€¦ · subprocess managers, quality engineers, etc. February 15th, 2005...

Documents

Transcript of Change Management, etc.€¦ · subprocess managers, quality engineers, etc. February 15th, 2005...