The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.


Scrum Sprint Zero

Posted by admin under Scrum Basics

So your organization has decided to implement Scrum, but you’re stuck, wondering what to do first. That’s understandable: For all of Scrum’s detailed processes, what’s the process for starting the process? Put another way, how does a team prepare for its first sprint? For many Scrum professionals, the answer is a sprint zero, a preliminary sprint exclusively dedicated to preparing for the first sprint. But which activities it includes, how long it lasts, and what it’s called are all debatable points.

In my experience, this sprint is best spent focusing on the team’s physical environment. This might include setting up computers, creating a team room, optimizing work stations, etc. Others, however, conceive of sprint zero as a chance to prepare the team for its first sprint planning meeting. For those Scrum professionals, that means sprint zero involves adding a few substantial items to the backlog and writing a piece of functioning code — no matter how small. This argument does make sense: If the first sprint kicks off with the sprint planning meeting, a Product Owner will want to have some estimated items in the backlog.

Since spending too much time on gathering requirements can lead to analysis paralysis, this sprint should be as short as possible — only as long as it takes to accomplish a few preparatory goals. Others, however, argue that sprint zero should be the same length as a regular sprint to help teams adjust to a regular work cadence. With that in mind, it’s not surprising that those who argue that sprint zero should be the same length as any other sprint also assert that it could just as easily be called sprint one. According to these Scrum professionals, the basic goals of sprint zero — design, infrastructure, process improvement, implementation, test, and validation — are the goals of every sprint.

Sprint zero is contentious among Scrum practitioners. Though they might not all agree on its name or how long it should last, sprint zero preserves the principles and processes of the sprints to follow.



Scrum with a Physical Taskboard

Posted by admin under Scrum Basics

Agile management practices, which include Scrum, were originally conceived for use in small, collocated teams. Ideally, a team’s size falls between five and 10 members, all of whom are located in the same place. With no obstructions to communication, that arrangement facilitates ongoing collaboration and optimizes the team’s productivity.

According to research, teams in such an environment prefer highly visible communication and coordination tools that reinforce collaboration. For example, physical task boards, dry erase boards, Post-It notes, index cards, and other “manual” devices are among the most effective ways to track projects for Scrum teams working in ideal conditions.

However, most complex development environments contain too many variables for small team, manual agile techniques to work effectively. As team members increase, the attributes that make manual agile so effective in small teams don’t hold up. In fact, they actually become impediments in large-scale installations. So how do team members uphold Scrum’s tenets of communication and collaboration when they’re spread across offices, buildings, or even continents? And how they replicate manual agile in this context? Facing the challenges of scaling teams usually requires an agile tooling solution. While there are several solutions available, including my own company’s product, ScrumWorks Pro, I will focus on the most common challenges to scaling manual agile.

Large Groups and Collocation
Collocation is essential for teams using manual agile. When everyone works in the same vicinity, posting requirements and updates to a physically visible location is a great solution. But once a project team grows in size beyond 10 or 20 members, it begins to lose its impact. In short, as the visibility of the posting decreases as a team member’s geographic distance increases. As the group grows larger and larger individual group members will become farther and farther from the single physically posted requirements backlog. In this case, some group members will be hindered by the lack of convenient access with requirements and prioritization decisions.

In scaled agile, individual teams could employ a taskboard, which would be a convenient information radiator for all team members. But others — such as related teams — would struggle to stay informed of the team’s progress and impediments, since the board is outside its members’ immediate proximity.

This is a problem that happens even when all group members are collocated on a single floor, within relatively close proximity to the backlog. Furthermore, this situation is amplified when team members are spread over several floors in a building or in different buildings altogether. Clearly, this problem does not go away when teams are distributed across countries, continents, and time zones.

Management of Data in Large Groups
One of the most common ways small agile teams store data, including stories and tasks, is with note cards. This marks another challenge of manual agile for large organizations. Regardless of the benefits of using note cards and sticky notes, it quickly becomes impractical when dealing with large projects.

Consider a project comprised of thousands of stories and ten times as many tasks. The task of sorting and organizing that many cards would be impossible. Suddenly, these cards would only be of value to those in possession of them, since creating and maintaining copies of thousands of cards only compounds the implausibility of the situation. Considering that cards are often revised, archiving would need to occur daily. In general, standard data organization functions are made difficult in large agile projects that use manual tools.

Visibility and Reporting Issues
Manual, paper-based tools work so well in small agile projects because they increase visibility and communication for everyone involved in the project. As mentioned before, however, using manual tools on large agile projects actually obscures data rather than make it more visible.

In such a scenario, reporting will struggle to keep up with real-time updates and may convey inaccuracies, thanks to the time-consuming process required to manually compile statistics. The backlog is a living, breathing artifact, with new cards being added, existing cards being altered, and obsolete cards being thrown away. For instance, a swing of 20 to 30 percent in total backlog effort from sprint to sprint is not unusual. For minimal summary statistics (net change), manually re-summing backlog effort is necessary each and every sprint. If more detailed change statistics are required, a manual change log of activities must be kept in tandem with the note cards.



Agile Two Years From Now

Posted by admin under Agile and Scrum

Victor Szalvay, CTO of Danuber Technology, makers of ScrumWorks, tells a story about his hope for the future of Agile in the next 2 years. “I think the coolest thing for Agile is if the core principles are still intact and hadn’t been corrupted by this push, this press for codification at the enterprise scale.”



Scrum Epics

Posted by admin under Scrum Basics

In Scrum, the teams that complete the work assign effort estimates to every user story. Of course, that assumes that a team can reach a consensus for an appropriate estimate. What happens when a story includes too many unknowns to tell just how big it is? Or what if the story’s requirements are known, but its effort is too huge to complete in a single sprint? We call these stories “epics.” While a team should be able to tackle a typical story in four to sixteen hours, an epic is a story that would require twelve or many more to complete. Most Scrum experts suggest that any task requiring twelve or more hours should be decomposed into several smaller tasks. These stories will not only be smaller in scope, but also more narrowly defined. Basically, breaking down epics helps the development team translate its work into chunks that can be accomplished in a single day.

Is there any danger to estimating an epic? Quite simply, the answer is yes. Estimating epics can be harmful because it creates a false sense of certainty for the Product Owner, who begins to believe that the belief that the requirements, tasks, and effort of the epic are known. When a team estimates an epic, that estimation is just that — an estimation — but it seldom remains a best guess. It is often used for forecasting, which, in turn, becomes the basis of a budget. When that happens, that estimate is now an inflexible projection that binds the team to complete an unknown amount of work while respecting an established budget. This strategy is akin to a trip to the supermarket with a fixed amount of money to spend, but no idea what needs to be purchased. It’s safe to assume that anyone in that situation would have plenty of questions. What am I making? What ingredients are in it? If I can’t afford all of the ingredients, which ones are the most important? Basically, this shopper is left in a tough position: He knows he has a meal to prepare and ingredients to buy, but, apart from that, he’s in the dark. The same could be said of the Product Owner who commits to an estimated epic.


Watch a team split epics during a Backlog Grooming Meeting.