Group items matching

in title, tags, annotations or url

existing solution to this problem was to lower the expected velocity each sprint, so the next sprint would be on-time. But at the end of next sprint, the same problem occurred, so the velocity was going down sprint after sprint.

pressure of the rest of the organisation for the team to keep up their tempo. This pressure from both sides was crushing morale.

The way this team reacted to pressure was to work harder. Most people would have 2 or 3 tasks in progress at the same time. When a developer would finish a task, the testers were too busy testing something else, so they could give the developer direct feedback. When the tester found an issue with a new feature, the developers were already working on something else, so the tester had to wait. Simply put, there was too much focus on working long and hard, not on cooperation and the stuff that actually matters: features.

most dysfunctional behaviour comes from the system people are in

biggest struggle of this team: pressure & predictability.

Most Scrum masters challenge the team to reach the same (or higher) velocity each sprint. This pressure should give a team focus to perform at its best. However, it can also go haywire if the team doesn't deliver. No focus, no pride, no happy customer

retrospectives were dismal and planning meetings were a huge burden. The teams' productivity dropped in the days after the sprint, finding new courage to start the next one. Because they had an ineffective work-process, the only outcome of each sprint was to lower the expected velocity, to make sure we would be predictable. Estimation and predictability are only a means to an end and since they were getting in the way of fixing the root cause (and were bringing down the team's spirit) I opted to cut out the planning sessions and sprint deadlines.

first change we made was to set a limit of 8 tasks on the 'in progress' column

We spent 3 weeks bringing the numbers of open tasks from 21 to 8, without picking up any new work. Of course the team struggled with this new limit. They were used to pick up new work whenever they were blocked somehow, this wasn't allowed any more

I told them I just saved them $12,535! They looked around to figure out how. The reason I was there was simple. Earlier that year, those same IT managers had performed a series of calculations to estimate how much it cost the department each time a bug made its way out of development, into SIT, into User Acceptance Testing, or all the way into production. For this IT shop, one bug into SIT cost them $12,605 (and you can imagine how much a bug into production would cost.)

magine a project team of between fifteen and four hundred people. There are user representatives, analysts, programmers, database designers, and testers, arranged in a pipeline. The user analysts talk to the users, and then to the analysts, who write down user stories. The analysts write lots of notes on each user story, since it will be a full iteration or two before any programmer will pick up the user story. The notes are between one and ten pages long. Eventually, a programmer picks up a user story along with the supplemental details, code them up in an iteration, integrate them into the growing code base, and mark their velocity. In the same or a later iteration the database designers do the same. Eventually the integration test team comes along, runs tests on the whole thing, and feeds bug reports back into the programmers’ work queues. The users or project sponsors may see the outcome every few months if they are lucky.

Collocate the requirements gatherer, the database designer, the programmer, the tester. Lengthen the iteration period to one month. Give the requirements gatherer a week’s head start on the features coming up, but otherwise arrange that all of them are working on the same feature set in the same month.

Break the pipeline, lengthen the iterations, lose the machismo, deliver the project.

here is no mechanism in the standard agile language that warns about this loss of touch. The currently standard language consists of ‘’iterations, user stories, ‘’and’’ velocity’’. By a perverse relationship between them, it is possible to equally shrink iteration length and story size, with velocity scaling accordingly. Thus, a team can feel as though it is become more agile, when in reality it is simply becoming more cut off from its user base and the feedback it needs to succeed.

The repair is simple: connect every activity to a release or delivery to real users (delivering to even one real user makes a difference). Evaluate the team’s work based on how often they deliver to real users and how long it takes a new requirement to reach the users. Replace the fuss around iterations with fuss around deliveries.

As an afterthought, if your new iteration length is a month, you can still run one-week planning windows to make sure you don’t get off track during the month.

Facilitate the Product Owner's role (backlog maintenance and meetings)

Among the Project Manager's responsibilities:

Tracking project risk

The Project Manager on a Scrum project has to be a Scrum expert and evangelist.

As each Scrum team on the project evolves their practices, the Project Manager will insure that they are continuing to work effectively with the other teams

One example of this would be the application of Test Driven Development and similar practices to build stability. It doesn't make sense for some teams to use TDD while others don't. The PM would have to step in and work with all the teams to insure that practices won't interfere or cancel each other out.

While starting at the team level with Scrum is often good, you often need to start with the product management team - that is, where product enhancements to be worked on are selected

Even when Scrum works at the team level, organizations very often report little impact to the bottom line.  While this is better than nothing (if the teams are happier, that's good), it usually doesn't justify a huge investment

in many contexts in which Scrum does not work readily, Scrum has no power to improve the context in which it is in.  In other words, the impediments that one must fix are often outside of the scope of what Scrum helps you do.

These impediments are often not even seen or if they are, are often viewed as "just the way it is."

certain Scrum attitudes often makes things worse

Scrum does little to let management to know how the team works or what impact management decisions have on the team

There is almost a religious zeal that Scrum tells you little of what to do

While SoS works well for certain types of work, it does not work well when the different teams have different motivations. 

the high failure rate is due to the fact that Scrum works in certain contexts but has little ability to change the contexts in which it doesn't work wel

One needs to pay attention to where to start as well as see how to change the context.  Separating the team from management doesn't help.  Focusing on only the team part of the value stream - giving little guidance both up and downstream of the team also doesn't help.  Lean provides guidance here (meaning Scrum with the aid of Lean could provide insights),

look into using Lean as a context for any improvement in your software development organization

While Scrum may be an appropriate choice in many circumstances, other methods may be better (e.g., Kanban Software Development).  Scrum's rapid ascension probably has more to do with its success in the places it easily fits.  Now that it is past the early adopter phase, we may see it having even a harder time as people attempt to scale it.