- Freedom of the team, since the team works without any bosses. As a result, the team has to be very responsible and work tightly together to solve problems in a challenging environment. The only limit to the freedom is the User Stories to implement at the end of the sprint, and the sprint’s objective to reach,
- KISS - “Keep It Simple Stupid! ”: Scrum rules are simple to understand. You don’t necessarily have to study and understand why it works, just follow the rules! Obviously, it is best to study project management theories and leadership concepts either to apply the rules with even more convictions, or to go beyond them once mastered. In theory (I don’t fully agree on that point), any decisions is done on a KISS bases,
- The capacity to improve ourselves with retrospective and brainstorming sessions. This allows us to state and agree that we are bad in such or such area, then take actions to change completely one or more processes. Any process belongs to the team, and it is its duty to improve or suppress it. No boss knows better the problem that the extended team (i.e. including the PO, the SM and the Team),
- I have done a few projects in AGILE, but what I find excellent with SCRUM is that it provides a worldwide proven project management pattern. Moreover, the best practices are basic enough to allow us: To apply them strictly, AND to add creativity so that it could be applicable to solve various problems,
- My aim is not to list all SCRUM’s definition, but if I had to pick up 2 great stuff in it would be : Rely on Time box nearly everywhere: In many occasions on an AGILE project (without SCRUM), when everything is important, some tasks are endless and we tried to cheet our deadlines, and add a bit more, and another team member a wee bit more, and so on. As a result, we resulted in the very well-known issue, that everyone knows : we were late, and the quality was bad !! By applying Timebox most of the time AND defining the rules beforehand with the entire team member ("definition of Done"), it is easier to stop it due timescale. As long as the ScrumMaster plays its role of leader so that the rules are applied.
- I just knew AGILE before starting a project with SCRUM. What I was really astonished by is its ability to predict the future, based on our previous sprints' experience!! Obviously, no rule is perfect and it is only estimations, but we managed to have a 6 months plan for instance, and identified risks. For example, a “Release Burnup chart” is simple, but it enables us to take important decisions few months in advance, and inform the project board and sponsors well ahead.
- It is a humble project management: no bosses, no experts, beginners are welcome. Personally, I found that later point bizarre and I doubted it on that point before trying it, then changed my mind. In fact, in our SCRUM project generated so much motivation and “helpfulness” that “beginner” and “experts” could work in harmony with efficiency. In addition, holidays or the turnover within our team was less a catastrophy due to the sharing of the information (eg. pair programming).
- The team is “self-organized” hence many decisions and tasks could be done in parallel: well, in fact, don’t forget that the ScrumMaster is here to lead the way, and although he do give any orders, a good leadership could indirectly tell what to do!
- I was surprised that, on quite a big project, our team was able to work properly with such a few emails sent!! In fact, we found out that most of our communication is done orally.
. emails are used when a fair amount of information has to be communicated and when a quick answer was required. In this case, those emails were followed by oral communication anyway. This is particularly true when you could have email server problems: Once, I found out only after 5 days that my inbox email were down, because on one hand we were often and on the other hand because my outbox email still worked.
. Documents in a common repository (such as Sharepoint) are used when large documents are to be shared. Never send those documents by email, just its link.
- Last but not least, we are just happy to work in such a friendly conditions, as long as retrospectives/feedbacks sessions are performed when something goes wrong!
Another major drawback, is that the tester is always required to catch us up and rewrite its GUI tests, so that the Software Factory is useful. As opposed to the ideal world where you write only one big GUI test according a detailed specification document (that would always change anyway in the real world !).
The good news is that, because the customer and the sponsor where strongly involved in the product's creation and could play with it, they were “sort of!!” happy to grant us more budget to perform some extra-iterations.