Categories
agile

Waterfall Model in Agile Sizes

I am a big fan of agile methodologies at all – if done right. Therefore, in my lectures, I teach about the big misunderstandings of the waterfall model, which never was told as such by Winston W. Royce in his paper “Managing the Development of Large Software Systems”. Actually, in his original paper, he described the error-prone approach he observed at this time.

“I believe in this concept, but the implementation described above is risky and invites failure”

Eventually, Bell & Thayer called this process Waterfall the first time in their paper ”Software requirements: Are they really a problem?”. 10 years later it became a standard in the Department of Defense Standard 2167A (DOD-STD-2167A).

When reading Royce’s paper carefully you will find a lot of recommendations pointing to nowadays agile practices such as iterative development, talking to the customer, performing reviews and even DevOps approaches as the fact software should be run by those who write it. All these things mentioned by Royce are never mentioned when talking about the waterfall.

But then again, when talking about agile you probably will realize, that it is nothing else than “Waterfall” just in small sizes as illustrated by @JishuaKerievsky:

Royce’s original paper: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
Paper by Bell and Thayer: https://pdfs.semanticscholar.org/a50d/8f564d063e526e94114875220440f64d8666.pdf

Categories
agile

Feedback Loops in Scrum the Other Way Around

Scrum in ActionUser Stories are the way a non-technical product owner can communicate with the technical team. It is probably the best way any product owner can tell the technicians what he or she actually wants. A the same time it is the best point to pick up technical requirements, limitations and pitfalls related to your requirements. Therefore, take this opportunity and listen carefully. The feedback loop is not only top down, it’s bottom up as well, you just have to use it.

A difference maybe not realized yet

The difference in Scrum related to many other development processes is the rapid feedback you might get during backlog grooming or estimation meetings. Developers will moan about the stories, complain about requirements and tell you more often than not, these particular wishes might be very expensive or even not possible to achieve at all…

Take Action

Even this might be exaggerated, listen because here you get feedback from the folks knowing the software best. Change requirements on the stories, modify the scope, prioritize impossible features down. Nobody else does understand the overall system that well. Non of your architects, managers or analysts understand the system that way.

No means Maybe Later

No does not mean no by definition. If you come up with a story, developers think its impossible, it’s actually not. Stop fighting for the story. Take it, go back to the drawing board and refine or start over. No simply means it too expensive. Always remember: We are talking about technology here. probably everything is possible. It is simply a questions about how much effort one (in this case the product owner) is willing to put into it. If developers say no, they come up with a natural instinct which tells them it simply not feasible under the current circumstances. Always remember, SCRUM is about performing on the very best level under a certain set of circumstances and limitations at a very specific point in time.

Resume

As a product owner make use of estimation meetings and/or backlog groomings. Go over stories again an again and pick up the feedback from your developers. With every meeting you will get better feedback more details and better estimations. Take this opportunity receiving rapid feedback from the developers. There is easier way to get this feedback, though.

Categories
agile

Teamwork in Scrum

ScrumMaster Logo SealSome aspect attracting my attention since my very first Scrum training is the fact how a Team actually handles team work.

In a conventional software development team you probably find a bunch of hierarchical organized group members including managers, an architect, engineers and developers. While the architect figures out what to do with respect to the managers needs, the engineers define how to do it and de developers eventually do whatever the hierarchical organization above has defined.

In a Scrum Team, the Team is told what to do directly by the ProductOwner in form of stories. Consequently, what to do, how to do it and the act of doing it is completely within the responsibility of the Team. In the conventional approach, each level could blame the level above in case of a failure. The developers blame the engineers for insufficient definitions, the engineers blame the architect for a faulty architecture or misleading bullet tracing and the architect might blame the managers due to a strict budgeting, too much pressure and so on. Of course each manager might blame his manager in turn and so on.

So, how do we end up in a team effect? I have seen teams where each developer picks a story from the task board, teams where each developer had his/her own area of stories (server, client, user interface etc.) and teams where the overall team works at one story at once. Boris Gloger, holds the view the entire Team (of developers) works on the same story. I am not absolutely sure yet,  how this works in larger teams (5+ developers) with small stories, however in theory, if a story is done by the hole team it succeeds as team.

If each developer works on a separate story, I recall a passage from the latest book of Robert C. Martin, talking about who breaks the code will own it. What’s the logical implication of this? If a developer breaks code he might get blamed by other team members. That’s the quick death to a team. If the team separates in smaller groups which maybe blame this developer, this might be an even quicker detach to the team. If the blaming happens in front of the ProductOwner, this might fundamentally harm the overall Scrum Team, in particular the Team – ProductOwner relationship. Suspiciousness, maybe shorter sprint duration and additional tension within the whole Scrum Team might be the result. The very best ScrumMaster will have a hard time undoing this. Considering the fact that a really good team might take up six to twelve moths to form up, blaming should be avoided at all circumstances.

So what’s the right attitude in this case? If something goes wrong, a story is not fully implemented, code is broken, previous functionality is lost or whatever goes to the dogs, the whole team should stand up, work together to fix this issue as quick as possible without caring who introduced it. Of course the team should perform a root cause analysis what exactly happened, however, as it should be done in retrospectives, the topic should not be what went wrong and who’s fault it was. Instead it should be about how to avoid such a issue in the future. That way its all about improvements and that’s what Scrum is about at the very end.