Alright, so here I am, again in an environment buzzing with development in SQL, .NET, Biztalk and all the other cool stuff. I have been formally branded a ScrumMaster, I have been informally branded a ProductOwner. I’m still a developer. I have been granted the privilegie to maintain and uphold the scrum process in our company.
Does it need to be upheld then?
First of all, to be upheld it first has to be established.
OK, but aren’t we doing scrum already then?
No, not yet. But we sure aim to do it. An interesting example of this is the Daily scrum meetings. The 15 minutes long, stand-up meetings every morning at 09.00. We do them. We talk about things done yesterday and things to be done today. It is not very often the impediments are mentioned. Tendencies are, though, that it takes quite a while for a user story to wander across the story board to the glorious column of “done”. Can it be so that unmentioned hindrances block people from working faster? Perhaps. Why doesn’t people mention the impediments then? My belief is that no-one really thinks the ScrumMaster has the power to make them disappear, and highlighting them then just makes it pointless. The struggle goes on in silence. To get rid of that fact the ScrumMaster needs to be the sweeping guy, the shit-fan-blocker and the one with the ability to make problems disappear. For those of you who read my earlier posts, Arne and Börje both were eminent ScrumMasters in this sense. People relied on them, and they mutually trusted their colleagues to get the things they were doing best, done. ScrumMastership is a matter of trust and also the capability to remove hindrances. This we don’t do. Yet.
Another obvious factor showing us we are not doing scrum is the Daily scrums themselves. If the ScrumMaster should happen not to be present in the offices on one day, the team probably wouldn’t meet for the Daily scrum at all. The DS is not for the purpose of making the ScrumMaster happy, it purpose is to make people aware of priorities and impediments. If you don’t meet up for 15 minutes just because the ScrumMaster isn’t present, question why you should do it at all.
One of the greatest things about the organization I currently work in is the team spirit. The members of the team have worked together for a long time now and everyone knows each others’ strengths and weaknesses. There is a lot of joy to the work, and no day is without laughter. People like what they do. However there is a somewhat individualistic view on most matters. People are used to having someone telling them what to do and when to do it. If tasks are handed out, they are done, but if a story just sits on the story board with no name on it, it migh stay there for some time. The problem with that approach is when someone puts their name on too many tags and don’t get them done. Since they are named tags no-one else cares about them. Team effort suffers.
If the named tags are an extremely unsscrummy way of doing thing, saying your work is agile when you keep doing all effort as a set of relays is even more so. The problem with this relayed way of thinking is that it has its roots in mass production industry where work flows as a continous process and where each and every step can be analyzed and refined successfully. “If we can make the assembly machine in stage 3 run twice as fast, we can raise production by 20%. If we invest in another packing line we can get twice as much done” is not at all analogous with “If we write the system specs twice as fast we raise production by 20%. If we invest in another developer we get twice as much done”. Industrial production and software production does not have many things in common since we in software seldom do exactly the same things repeatedly. If we do that we are actually doing something terribly wrong. Industrial prodcution however has its’ sole purpose in trying to do the things exactly the same every time. Where the sequential thinking in on production line is the life essence and a quality factor, it is totally devastating for the other production line. You do the math.
Therefore, working in small waterfalls or “scrummerfalls” where all devs sit around waiting for the system specs to be written, and all testers hanging round to wait for the code to be produced is not scrum. It certainly is not agile. Scrum is about extensive communication and getting things done. As a team, not as a set of individuals. My friends Per and Patrik knew this. The fellowship under Börje Mellander knew this. Mature teams work agile, wheteher they call it scrum or not.
Scrum is a way of thinking. It may sound corny, but it is. If you don’t know why you do things there is a severe risk that you either do them wrong or not at all. Both these symptoms still occur in our organization. Let me give another example from what occurred just the other day.
A client calls in a request for a new feature. The call was collected by one of our business analysts who immediately started to plan the work, allocating the resources (stamping the name of a developer and himself on the task to be done). In a fury of creativity, the user story was also estimated and practically sold to the client based on that estimate. Furthermore the story almost went its’ way all the way to a sprint (or iteration may be the better word for it), not yet existing. Of course, Everything was done with the best of intentions, and a lot of work was put into it by the business analyst. It however breaks almost all the principles, ceremonies and artifact stated by scrum.
A scrum way of doing this would be to collect the request and politely tell the client that we would get back to him or her in a short while. As the user story was added as thoroughly as possible to the product backlog the product owner is notified of the story’s existence. If the business analyst then makes his or her case well enought, it should be really easy for the product owner to make the story prioritized for the next planning meeting. The effort however is not touched by neither the analyst nor the PO – it is a matter of the team to decide as a collective group effort. If the effort is small enough to fit in the next iteration it is placed there. The call back to the client then would have a better estimate, a commitment by the product owner and a commitment by the team together with a possible release date and demo date (end of the sprint). If the client then says go, its is to be done. If it considered to big an effort or to expensive, since the team has broken the story down (during the planning meeting) it is much easier to discuss partial deliveries, workarounds or other ways of delivering the feature. The same thing happens if the story is to large to fit into the sprint box. It is then broken down and delivered as small increments over several sprints.
Why, then, is this approach better than that of my beloved colleague’s? Well first of all, early commitment is bad since the commitment becomes a matter solely between the analyst and the client. All other involved can rely on saying “Your estimate is faulty.” “I have other things do do right now.” “There is a better way of doing that.” etc and never really commit to the deal. By making people aware and part of the process you avoid that. Furthermore, by planning it to an non-existant iteration is risky since priorities change over time. Just because we have slack in schedules right now, does not mean we have it next month. Things important today are irrelevant tomorrow. Planning and commitment should be done as close to the construction as possible. Also making the team taking responsibility for development of the feature is an assurance that it is really done. If you early in the process pin the task to one or two developers (tagging the user story) you are not only actively neglecting knowledge sharing, you are also adding to another person/persons workload without their knowing or commitment. Further, you are actively making other people unaware. “It is not my name on it, why should I care?” Of course you also have to deal with problems that occur when the tagged name cannot complete the quest. You end up in a mess where things have to be handed over, documented in excess, re-written etc. If you at that point already have made a promise to the client it can be quite inconvenient to suddenly have to tell them the feature takes more time to complete, becomes more expensive or such. So, just avoid that path.
I often hear people around me saying things like: “You know, we’re not like Microsoft or IBM, scrum does not fit us to 100%”. “We are unique”. “In our environment, things are not that simple since…”. All of them ar true of course. We are not Microsoft, we are unique and things are never simple.
The most important thing is to remember why we are trying to do scrum in the first place. We are trying to get things done, shortening the time-to-market, enhancing the quality and making the customers more satisfied. So far we are just like Microsoft, not very unique, and sticking to scrum is in that way easier than sticking to the old waterfall models since there are fewer things to grasp in scrum.
Even if you don’t embrace scrum or the agile methods, feel free to drop a post explaining to me why other ways are better.
@stakes 