Mahyar SEPEHR

This week took place the Paris Java User Group (JUG). It’s more and more crouded there and it’s a good place to be to know more about the hottest subjects around Java… This week the subject: SCRUM.

Three weeks ago, i had a two days training of some classical Project Management where we discussed about Product Breakdown Structure, Work Breakdown Structure, Pert Diagram, Gantt Diagram etc. Very interesting. It is interesting to realize that the same process can be applied in Aeronautics, Architecture, Automobile or in Software development. It sounds possible but it also sounds logical to thing that it can imply unnecessary costs when applied as a routine.

1st thing that catches my attention in Scrum is that some experts from software development asked them-selves: ok, but can we build some models optimized for some management of software development projects?
2nd : the Agile Manifesto focuses on communication. Here, communication is not mail or document written but people talking to each other.
3th : Scrum is based on iterative incremental process (N Sprints) with the recognition that the client will change its mind during the process

Roles:

• Product Owner: the voice of the customer, it is not always a same person.
• The Team (developers, but also architects!)
• A Scrum Master

Inconvenients:

• It is far from the classical company structure and people could be afraid of loosing their position in this new hierarchy. Are the Product Director or the Product Owner ready to see anything else than a Microsoft Project Chart? A Burn Down Chart which is a far more simple Chart compared to the Microsoft Project Gantt Chart is not always accepted…
• It requires that the client should be a weekly or daily actor of the project. But what if the client can not do that or does not want to have this responsibility?

The second part of the JUG Presentation discussed about use cases with some main questions that Scrum has to answer.

The main idea that interests me is that experts in Scrum do not consider a classical project as fake. They realize that frontiers are not easy to change and Scrum should represent sets of practices maybe some “Best Practices” that one can bring in to one project if needed.
For example, one method that i would try in involving users, customers, the Team is the “the Daily Standup”. It is a short meeting where people talk in few words about what they did yesterday, what they are doing today and if they find difficulties. This approach is clearly the Best. The Product Owner, if present, has a live feedback and the Scrum Master knows if everyone is accomplishing its goal. This meeting is timeboxed and should take only 15 minutes.

It was a pleasure to discuss with people who are experts and not fanatics!