February 21st, 2007
When is Scrum not Scrum?
In teaching Scrum during the past year, and working with organizations in a consulting/training capacity I have found more and more that some of the principles as outlined in the two Scrum books are out-dated and unhelpful. I teach what I know works and what I see as being appropriate; there are slight differences in each context of course, but there are certain practices I have found to be effective, all of which differ from standard Scrum practices; some would be considered radically different, which leads to the difficult question, the title of this essay: when is Scrum not Scrum?
1. Product Owners are part of the team.
Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture. I discarded the distasteful “pigs and chickens” terminology a long time ago, and now encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings. To do this successfully requires a different mindset from everyone involved, so the style of training and adoption needs to change accordingly. This is not trivial.
2. Two-week Sprints
Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed. Today it is far too long. It is also true (from my experience) that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming. Most teams I have tried it with nail the first part of the sprint, but allow the second part to be vague and muddy. They get exhausted by the eight-hour meeting, and simply find the time frame too long to plan effectively. A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.
3. Tasks are not measured in hours
Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach. In my experience team members find this practice frustrating and meaningless. Long ago I moved towards encouraging team members to break all tasks down as small as possible. A task must be completed in a single working day or it is considered an impediment, and should be marked as such. This approach serves two purposes: firstly, ease and accuracy of burndown (burndown on tasks rather than hours, making the whole process binary: a task is done or it is not done) and secondly it raises impediments which developers themselves may not see. For example, an incomplete task may be in that state because a developer was called off into some long and meaningless meeting, but because “that is the way we work around here” this is not seen as an impediment. Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.
4. Use of Taskboards rather than spreadsheets
The Scrum books, and many CSM courses promote the use of spreadsheets to track the sprint. This is really horrible. Spreadsheets hide information, and they lie. The best way to create transparency is to display everything on Big Visible Charts. The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can. Taskboards can work with distributed teams too, by having proxy updates (via telephone) and sharing photographs of the board on a wiki — every day.
5. Backlogs on the wall
Again, moving away from spreadsheets. At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time. Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case. The less time we give to thinking ahead in detail on features that may never see the light of day the better.
6. Estimation Meetings
Estimation is done before the first sprint, and then on a regular basis during each sprint. I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time. Estimates are done in Story Points, as described in Mike Cohn’s books (not “ideal developer days” as described in the Scrum books). The estimation meeting is an integral part of a successful cycle. Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.
7. Insistence on Agile Engineering practices
It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t. It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start. This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed. Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices. I have seen this approach fail too often to have any faith that it is true. Intuitively even, it seems likely to not be true.
8. The Scrum Master role is not always necessary
An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to. The Scrum Master role becomes superfluous in a healthy Agile organization. There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people. Coaching should be appropriate to the context. I have seen a lot of lousy Scrum Masters, falling into old PM habits, and having teams simply accept it, because that is how they are used to working. I also have issues with the term Scrum Master; language often dictates how we behave, and this term doesn’t help to break paradigms.
So is what I do Scrum? Perhaps it is; there is enough of the original flow there to claim so: planning meeting, daily meetings, delivery of working software each sprint, retrospective, but ultimately the name itself is superfluous. The Agility inherent in the principles I teach and coach to allows fundamental change to take place in organizations. That is what I am after. If it helps to call it Scrum, we can call it Scrum. It offends to call it Scrum we can call it something else. Eventually, it will simply be “what we do”.
Scrum is a useful framework to get started down an Agile pathway, but if the framework becomes a rigid way of thinking it destroys its own purpose. The reason so many organizations struggle with Agility is because they want a quick fix. Scrum purports to offer that through its two-day “Certified Scrum Master” course. It is a superficial and ultimately unhelpful approach, and one that I am glad, finally to be disassociated with.
On 30 January 2007 I was fired from the Scrum Alliance for challenging the leadership on issues of integrity and transparency. I no longer teach CSM classes. The official reason for the termination: “…the effort to sustain you has exceeded the benefit you bring to the ScrumAlliance over the last year” is a little unclear to me, but it was my time to move on, so there are no hard feelings there, and it does allow me to begin to explore Scrum and Agile in new ways. If we don’t press for change, as context of place and time dictate, then we are in danger of becoming that which we set out to challenge: another silver bullet with fixed solutions to fit every problem. And the Scrum Alliance is in danger of becoming another command and control organization, shot through with rules and contracts to control the course of this new silver bullet. I reject that approach: I embrace chaos, and I embrace holistic, context-sensitive approaches to creating essential change.
Update: In November 2007, at the Scrum Gathering in London I was invited to rejoin the Scrum Alliance by Ken Schwaber, its founder and chairman. Ken and I had always maintained a good professional friendship, and I had watched the Scrum Alliance grow and change over the year, eventually hiring the excellent managing director, Jim Cundiff, who is instrumental in moving the whole organization towards a much more self-organized model, in true keeping with its principles. I was happy to accept, and to re-apply for CST status, which I received in January 2008. My love for Scrum, and for the people in the community is alive and well and I am proud to be serving the community as both a coach and a trainer.
February 22nd, 2007 at 12:27 am
Hey Tobias, I agree with everything here except about the engineering practices. I’ve written more on my blog here:
http://www.agileadvice.com/archives/2007/02/when_is_scrum_n.html
February 22nd, 2007 at 3:40 am
Tobias, I agree and coach similar adaptations.
I generally call it Agile Software Development so as not to be tied to any orthodoxy or brand names.
February 22nd, 2007 at 5:01 am
Hi Tobias,
Agree with most of your points. Don’t agree that the SM role goes away, but I think that is in how we each define that role. More later on that.
Re engineering practices… I do agree with your point that too many think Scrum is “easy to do”. And don’t tackle EPs with sufficient vigor.
To me, though, the assumption is that the SM (if no one else) must insist that progress is made on improving them. (Exactly what that progress will be, the Team should agree on.) Of course, the SM (and others) must be convinced that improving the EP’s is the biggest impediment right now. Or one of the top 3, say.
Re “wrapping around existing EPs”. To me, this only means “you can start from here”. As opposed to the unhelpful “if I were you I wouldn’t start from here”. (In other words, “don’t start Agile until you spend lots and lots of time fixing your EPs to my standards.” You can see the box this would put people in. Arguably worse than your concerns, legit though they are.)
In my land of Scrum, there never was (nor should be) a sense that the existing EP’s are just fine, thank you. They always always always need to be improved.
February 22nd, 2007 at 6:42 am
Fantastic post!! Especially the part on excel sheets. IMHO, excel sheets tend to become like the old PM tools – only the scrummaster updates it, no one ever looks at it, and everyone is in the dark again.
February 22nd, 2007 at 9:30 am
Tobias,
I was in one of your last CSM classes and I have to say that the impression I got from you was that you were someone who was committed to see things work for the better. And I feel that is perhaps what is coming across here. If scrum gets in the way, then don’t do scrum. Use the ‘inspect and adapt’ philosophy to arrive at something that does work.
You are a journey man who has ideals and you won’t be boxed in. It’s like anything in this world. A small spark ignites a revolution. The revolution grows and the bunch of rebels needs rules and guidelines. And before you know, you have institutionalized the movement. The movement ceases to move. The revolution becomes too civilized. The free become the enslaved.
It is a well known phenomenon. I have experienced it with other movements, namely the movement of Jesus. Here we have the most radical leader the world has known, who started a movement 2000 years ago. But the church has institutionalized the movement. What was supposed to be radical and exciting and the essence of life and freedom, now comes across as conservative, dull and legalistic. Until a new revolution starts the movement rolling again…
I respect you Tobias and I hope you never lose those ideals that you so evidently have in your heart.
Later,
T.
February 22nd, 2007 at 2:28 pm
You need to write more blogs. This was insightful and will make an impact on how I organize my teams.
I completely agree with your comments about SCRUM being a useful framework to get one down an agile path (The Tao of Agile). I personally think we should all strive to understand the many perspectives and alternatives available to us (and some we haven’t thought of) to help us deliver value to the organization, whatever that may be.
February 22nd, 2007 at 7:15 pm
Thanks for the great post. Our team has just started to develop a process based on Scrum and have already made some of the adjustments that you mention (although I am still very much trying to assume the role of Scrum Master). We just shortened our Sprint time to three weeks for pretty much the same reasons you mentioned.
I recently completed the two-day CSM course and while I did get some useful things out of it, the commercial undercurrents of the Scrum License and the paid registration with the Scrum Alliance as a “Certified Scrum Master” still does not feel right to me. I applaud your decision to not toe the Scrum Alliance party line and wish you all the best in your continued exploration of Agility.
+1 on what Shane said about you writing more blogs.
February 22nd, 2007 at 11:00 pm
I recently ran a project where we held 30 to 40 minute Scrums every working day and the Sprints were, in effect 7 to 9 hours long depending on how long people stayed in the office at night! After 6 months of getting absolutely nowhere with an MS Project plan that ran to over 500 lines [and could easily have been over 1,000 if the anal project delivery director had her way!] and was utterly impossible to maintain as no one ever read it, this short sharp burst approach was the onl was to get things done and lift morale. No one knew they were Scrums [I never explained] and the only improvements I would have made would be to have the coffee and tea already poured so people did not get held up in the canteen before the meeting and to have no tables and chairs so we could have saved 10 minutes per meeting! Mobiles were banned too!!
February 22nd, 2007 at 11:14 pm
We are just being introduced to scrum at work and I’m a little skeptical at this point. What group size is scrum methodology effective for? We only have 9 people in our development group.
February 23rd, 2007 at 1:55 pm
Great post. The practices that you are describing are common place on Extreme Programming projects. Comparing XP and Scrum is at once a simple comparison of practice and a complex comparison of values and beliefs. I think you’ll find more resonance with your beliefs across the XP community than the Scrum community, particulalry your views on certification.
We are a lesser group of CSTs without you. You counter viewpoint was always welcome and always constructive.
February 23rd, 2007 at 5:21 pm
Thanks for the article Tobias.
In my last CSM course a lady with PMP background pushed her team into using Excel on her laptop to manage the backlog, instead of the big visible physical system I recommended (large post it notes on the wall). In the retrospective, the team convinced her this wasn’t working and they reverted to the big visible system.
I miss working with you, let’s team up on some project soon.
–mj
Michael James
Danube Technologies, Inc.
http://danube.com/blog/michaeljames/
http://scrumworkspro.com
February 23rd, 2007 at 8:43 pm
Tobias:
Nice post!
Over the years my way of using Scrum has also evolved similarly to what you describe.
Among the more noteworthy points, I, like you, favor the two-week sprint over the thirty-day sprint. In your experience, a truly agile team could nail all of the work during the first two weeks, then would struggle through the end of the month. My initial utilization of the two-week sprint, however, was to get teams moving faster during the first two weeks!
Even some of my better agile teams really wouldn’t get going until the last two weeks of a thrity-day sprint (virtually all of the work would be completed during the last two weeks).
The difference between a two-week sprint and a thirty-day sprint is not unlike the difference between attending school under a “quarter” (ten-week) system vs. a “semester” (six-month) system. Students in a semester system will wait until the last ten weeks to begin their term paper, while quarterly students need to work the entire time to meet their term paper goal. With thirty-day sprints, the team always knew that they had “plenty of time” to do the work, until it almost became due. (Note: Even “Good” students, like “Agile” teams, could be guilty of procrastination – especially if offered the opportunity to procrastinate).
I also firmly believe that sound Engineering Practices must be used while doing software development using any methodology, including Scrum. I particularly like the practices described in “Practices of an Agile Developer: Working in the Real World” by Venkat Subramaniam and Andy Hunt. This book has a great removable card with “45 Tips” for the Agile Developer – really good stuff).
I have additionally always insisted that the Product Owner be part of the team (although getting them to attend the daily scrum can be challenging!). When I play the Scrum Master role, I interface frequently with the PO in order to resolve functional inpediments so that the team can keep going. Because of this kind of activity, I still believe that the SM role is important. Even with a fully-empowered agile team, there are times when an SM is needed to work impediments in order to enable the team to remain productive. Having team members chasing the Product Owner around, for example, can significantly impede a team’s progress and lower sprint output.
In our organization, we do update Big Visible Charts throughout each work day in common areas for each team. However, because, we have sixty teams with nearly six-hundred team members in both the U.S. and India, we have been mandated to use VersionOne.
My boss (who first introduced me to Scrum), really hates “tools” (”Individuals and interactions over processes and tools”). Nonetheless, we have a PMO that monitors VersionOne regularly to ensure that we all keep the data clean and up-to-date. What can I say. At least it’s not as bad as using MS-Project for multiple projects with a common resource pool, Earned Value Reporting, etc. – that was a full-time job for me not that long ago.
Bottom line, many of us no longer follow the vanilla Scrum flavor first developed twelve years ago. Nonetheless, I believe that you and I are following enough of that original framework to still call what we do “Scrum”.
As you also know, I, too, was expelled from the inner sanctum of the Scrum Temple. In fact, I got the axe on January 26th, four days before you did. The difference is that I really wanted to remain, while you now feel free.
John H.
February 25th, 2007 at 5:18 am
[...] Agile Thoughts » Blog Archive » When is Scrum not Scrum? (tags: agile scrum) [...]
February 25th, 2007 at 10:12 am
Hi, Tobias.
Scrum seemed to be going through a defensive phase round about the turn of the year. Let’s hope it’s getting better now (Hey, your kids are grown up now – time to give them some freedom).
With respect to 2 week sprints, normally I’d agree. My concern is that sometimes this forces the ‘Divide and Conquer’ to cut the problem too small before letting the sprint team loose on it. That is, just occasionally the size of the problem that should be addressed as a whole is bigger than a two-week problem. Okay, I’ve only come across about 2 of these in the last 15 years, and I might have managed to subdivide them effectively if I’d known more, and in any case we could always re-work in the second 2-week sprint…
February 25th, 2007 at 11:18 pm
[...] Via InfoQ, I found Tobias Mayer’s When is Scrum Not Scrum? to be an interesting read. Some choice quotations: [...]
February 25th, 2007 at 11:22 pm
Tobias,
Nice! post. There are moments (I hope) in everyone’s career when work does not feel like work. If we can (and help others to) distinguish and mark that territory, and then draw a line, and refuse to retreat from it, we will have cultivated conditions for an environment where, instead of “work”, we call it “what we do”. We’ve all been there. You seem to be perched there, and you make it look attractive.
Boredom and ennui are products of equilibrium. You use the right brain of the organization to prod the left into response mode. Nice work! And when we are truly engaged, physically, intellectually, emotionally…we are simply “doing what we’re doing”…Ages Quad Agis….
February 25th, 2007 at 11:27 pm
“Ages Quad Agis” means “Do what you’re doing”. I only learned the 2nd half of the quote recently…”Suffer what you’re suffering” (forgot the Latin) Adds a little meat, doesn’t it?
February 26th, 2007 at 3:35 am
Howdy Tobias,
> 1. Product Owners are part of the team.
XP actually has the same separation, even sometimes distinguishing
between a “customer team” and a “programmer team”. (Kent Beck’s
comments in his debate with Alan Cooper a few years ago come to
mind.) I’m fond of the idea from the Takeuchi/Nonaka article
(introducing what they called the “rugby” project style)
emphasizing that “cross-functional” includes everyone from
marketing to manufacturing. The project sponsor gives a big
audacious goal for the project together with a fixed time frame,
and from then on, figuring out what to actually do, and doing it,
iteratively and collaboratively, is all within the scope of the
project itself and the responsibility of the whole project team.
> 2. Two-week Sprints
I always do 1-week iterations. However, that’s really just the
primary planning cycle — I really see iterations operating in a
recursive or even fractal manner on many time scales. We also do
planning and review on a roughly monthly release cycle, and also
on a roughly quarterly strategy cycle. *And* we do similar
planning and review on a daily pairing cycle. At every level we
can start the cycle with a little bit of planning, and then go do
the work, and then finish the cycle with a review of the work and
of our process. I also think that our goals at all of those
levels, from the largest to the smallest, can be specified in
user, not technical, terms — that is, I like to break down the
user stories for a week into tiny user stories, not technical
tasks.
> 3. Tasks are not measured in hours
My tasks are typically less than an hour, so measuring tasks in
hours would be a little silly.
> 4. Use of Taskboards rather than spreadsheets
Most often, I don’t bother breaking down tasks until I start a
story, and then just jot them as bullet points on an index card
together with my pair. On one project, we found that we were
consistently missing some kinds of things that the PO expected, so
at the weekly planning meeting we wrote each story for the week on
a whiteboard and brainstormed “tasks” with him, which we also just
wrote as bullet points under that story on the whiteboard. As each
task is completed, it is simply checked off on the whiteboard.
Again, these “tasks” were stated in user-oriented terms, really as
mini user stories, not as technical tasks, so they made sense to
the PO. For example, if the user story is “Student enters
profile”, we might break it down into “Student enters first name”,
“Student enters last name”, “Student enters email address”,
“System validates email address syntax”, etc. — and *not* “Create
profile table”, “Code profile screen”, etc.
> 5. Backlogs on the wall
Yeah, always. I was actually very surprised by the use of
spreadsheets in the Scrum literature — quite a step backward!
On my current project we have the upcoming release (2-4 weeks)
laid out neatly with cards taped to a whiteboard by week, all past
weeks taped neatly to butcher paper on the wall, cards for the
next release in kind of a cloud on the whiteboard, and future
cards in a few clouds on the wall, grouped roughly by priority or
feature area. The cards are also color-coded by user role.
> 6. Estimation Meetings
Yes to story points. I’ve only rarely done an estimation meeting
before a planning meeting, if there are a large number of new
stories being introduced. On my current project, we’ve actually
been pretty lax lately about explicitly estimating at all — we’ve
gotten pretty good at breaking stories down to reasonably-sized
pieces in the first place. That is, we don’t bother writing
numbers on the cards because all the stories are about the same
size, typically less than a day of work.
> 7. Insistence on Agile Engineering practices
I guess I don’t really know whether just doing agile planning
practices (a.k.a. “doing Scrum”) will lead automatically to agile
programming practices, but I have found value in introducing the
agile planning practices before the programming practices — I
think that’s where the biggest bang for the buck is to be found.
I’ve even seen merely introducing a daily standup meeting to have
noticeable positive effects on a project. I wouldn’t stop there,
though, and would keep reminding everyone that we’ll work on the
programming practices soon…
> 8. The Scrum Master role is not always necessary
There are many related roles that might be worth identifying –
coach, trainer, mentor, facilitator, tracker… I think everyone
on a healthy team steps into each of these from time to time,
though an explicit coach is valuable during transition periods.
The image I’m not so fond of is the ScrumMaster as process cop or
sheepdog “protecting” the team from outside interference. If
that’s necessary, larger organizational change is likely in order.
Cheers,
Justin
February 26th, 2007 at 4:45 am
I agree with most of what you say. There appears to be a marketing phobia around Scrum these days and the Scrum Alliance oblivious of their enthusiasm soon would take themselves into a counterproductive mode.
I used to like many things in Scrum and found that many practices in it were imbibed from the rationale in TOC (Theory of Constraints, TOC Thinking Process and Critical Chain Pradigms). Therefore they were very practical.
Today the Scrum Alliance appears to have made a mockery of this great system by touting a 2-day Certification Program and to me it looks a total farce of making a fast buck. The so called certification program adds no value. I wish Scrum Alliance took accountability and responsibility for those they certify as official Scrum Masters and Scrum Trainers. I remember reading with great interest, Kent Beck writing about certification in his XP Second Edition and how accountability should play an important role where the certification organization takes responsibility and accountability for those certified and the value add caused by such progarms.
I have been practicing, coaching and training in XP and other Agile Methodologies for over 6 years now.
Hope someone from the Scrum Alliance takes note of this and stop the Fanatism and Sales Pitch that they are creating around it. They may end up killing the great valuable Golden Goose in their effort in trying to cash-in on it too fast by unethical advertising and PUSH SALE.
All Agile Methodologies profess that Customers should Pull Value. You cannot force it down their throat and make money out of it.
I donot see a win-win for people attending the Scrum Master Training programs all around the world paying through their nose for it and falling into trap of yet another rat-race run by the Scrum Alliance.
February 26th, 2007 at 9:23 am
Tobias,
Your point on time tracking — how would you track time on the project if you don’t record how much time is spent on tasks?
–
serge
Response: If you really must track individual developer time for billing purposes there would be little overhead in having the developers write down how many hours the task took, after they have completed the task. This will guarantee absolute accuracy of the number, and takes virtually no time or thought.
February 26th, 2007 at 12:41 pm
Hello Tobias,
funny thing, 5 of the 8 things in your list were teached that way in my CSM. So how exactly do you differ from Scrum?
Response: The comparison is made with the Scrum books. Many CSM/Ts still teach the principles as outlined there. That you had an instructor who taught you according to most of the principles outlined here is inspiring. I can guess who it was, too
He is a colleague and a friend and we share many of the same values and ideas.
February 26th, 2007 at 3:12 pm
Very interesting and insightful. Especially bullets 1-3 and 8 have had me confused lately. I have observed some of these issues as well but was not ready to accept that it was not me that was doing Scrum wrong. Thanks!
February 26th, 2007 at 9:43 pm
Great stuff!
Maybe we are seeing the birth of “agile scrum” in contrast to “traditional scrum”?
To me Scrum originally evolved through a need to be more dynamic and agile, after years with static waterfall models. A static Scrum process at this point cannot stop the evolution, even if some organisation tries to squeeze more pesos from it.
Jens @ IntelliJens
February 26th, 2007 at 10:21 pm
Interesting ideas. I guess it depends on the organization. I do use an Excel spreadsheet for Sprint progress tracking – ironically, I do this because posting to a wall would not provide good visibility in our organization. The spreadsheet is on Sharepoint where everyone can see it – putting requirements on a wall would almost guarantee fewer people saw it. It is color-coded – lines in white are tasks still in progress, lines in yellow are complete. Very visual and easy to understand. As ScrumMaster, I update it. Mainly I do this so my team doesn’t have to (they have a corporate-mandated tool they enter their time into – I didn’t want them to have to do it twice.) As to how closely one should feel bound to follow Scrum rules – I have a team right now that is pretty much used to doing whatever they feel like. They pick and choose requirements as though they were the product owner. I was brought in to teach the organization Scrum and, at least for now, I keep them pretty much within the rules of Scrum. It chafes them but I cannot see any other way to break some of the bad habits they have acquired. Once they truly are a self-managing team and stop doing things like shuffling requirements into and out of the Product Backlog on their own personal whims, I am all for seeing what happens by loosening up a bit.
February 27th, 2007 at 7:21 am
[...] Go… [...]
February 27th, 2007 at 2:42 pm
[...] Tobias Mayer asks When is Scrum not Scrum? In his post, he questions if all of the principles outlined in the Scrum books are still appropriate today. Further, Tobias wonders if how he builds software is “Scrum” or not. Here are some of my thoughts. [...]
February 27th, 2007 at 7:13 pm
“Estimates are done in Story Points, as described in Mike Cohn’s books (not “ideal developer days” as described in the Scrum books).”
Can someone elaborate on this point? I’m interested in the differences/similarities…
thanks
t
Response: IDD is an estimate of time, while Story Points is a estimate of size. Really, the best elaboration is to read Agile Software Development with Scrum by Schwaber/Beedle and User Stories Applied by Mike Cohn.
February 27th, 2007 at 8:26 pm
I have a feeling that this blog post is too simplistic and idealistic and quite removed from reality
Response: Would you expand on that feeling? All that I have written here comes from working with actual software teams in practice. It is simple, it does seek ideals, and quite likely it is very far removed from the reality of most software engineers in the world. All of this is good: it is as it should be. But I’m interested to hear more about your concerns.
February 27th, 2007 at 9:55 pm
I’m still having members of the team question, why a task board & not a spreadsheet. Even after explaining to them that it needs to visible. The team feels that the task board is a waste of time & does not add value. And they are convinced they are less efficient by using the task board. HELP!!
Response: Without knowing your context, and what really causes the resistance it is difficult to respond to this. There has been some discussion on taskboards on scrumdevelopment. Here is one brief email on the topic, from a deeply nested thread of emails branching off in many other directions: Taskboards. If you do a search for ‘taskboards’ on scrumdevelopment you’ll find some other references. Boris Gloger has written a good article on the benefits that taskboards offer both teams and management. The article is available here.
February 28th, 2007 at 10:41 am
[...] Visit the link to read what he’s saying. [...]
March 1st, 2007 at 5:27 pm
[...] It’s not all gloomy though. There is now a reasonably structured and ongoing effort to improve the overall code base which has a lot of broken windows. At least the interface is looking sleek again and are almost fully up-to-date with our dependency libraries. We are now strictly using Subversion for source control combined with Trac for our bookkeeping. Even better yet, my project lead and I agreed on an iterative development scheme with cycles of two weeks which looks an awful lot like the process described by Tobias Mayer on his Agile Thinking Blog. 27bc [...]
March 1st, 2007 at 7:54 pm
Hi,
I like your no nonsense style, and I can see how these things have worked out for you. I have seen teams coming to similar way of working in some points. But I have a feeling you missed the point here. What you did is basically to find a way for Scrum to work for you, in your context. For me the point is in learning and adapting. In other teams or projects/setting other things may work better.
Response: I agree with you. It is about adaptation to suit the context — always. What I tried to capture here were some generic ideas that work across many contexts: shorter sprints, taskboards, etc. and also to make suggestions for breaking with tarditional Scrum practice, when appropriate: PO as part of team, Scrum Master unnecessary. My context has been wide and varied, these suggestions come from working with many teams in many contexts.
I also find some of the issues you discuss not so relevant. Whether you use hours for estimation, for example. I find your experience very interesting, and I like the idea of breaking down tasks, if your situation allows that. However, I feel that there are other, more pressing questions still open with Scrum. For example, if we are talking about the role of the Product Owner, the big question is how does one balance the interests of different stakeholders to select the contents for a release. Or, how does one manage “scrum of scrums”, or even worse, in a setting where product is build with partners.
Response: Balancing the role of different stakeholders is a fascinating problem. Solutions are centered in finding ways to reach consensus, and/or consent. I plan to write a bit more on that some other time. The “scrum of scrums” issue is also outside the scope of this article, although I would recommend not even contemplating a multiple team scenario until the core principles of Agile are well understood by the organization. When that occurs, solutions to multiple-team problems will emerge naturally.
March 1st, 2007 at 8:10 pm
I agree with most of your points but wonder how you handle points 4 and 5 with a globally distributed team? I would love do everything manually but team is spread over three countries (Canada, the UK and US).
From my point of view spreadsheets (whether Excel or Google) are the way to go. I minimize the burden on my team by doing all of the maintenance.
Response: The question that comes up for me here is: why is the team so widely distributed, and what can we do to improve that situation (striving for the ideal: colocated team)? Finding tools to work around the problem, no doubt helps you, but perhaps it also serves to hide the real problem.
In addition I find that developers are often reluctant to break tasks down into small chunks at first. Better to let them start with large chunks – struggle and then adapt than to insist on small chunks up front.
Response: I agree. And if you highlight the struggle visually, you will find the change occurs more swiftly.
March 2nd, 2007 at 7:10 pm
In your response – you asked why is the team so widely distributed? Because of acquisitions. My team will developing a 2nd generation product to replace the one originally required. The people who have the experience developing the original product are in the UK and the US. The people with the experience with rich client development and modern software engineering practices are in Canada. None of us want to move – so we make the best of an imperfect situation.
Yes it would be ideal if we were co-located but we were not. On the upside its very refreshing to discover a problem late in the day send off an email describing the problem and have the fix checked in before you start work the next morning.
Response: I undestand. Are you finding ways to share the knowledge so it is no longer contained in just one location? Is there a potential in the near future to reorganize the teams so all members are in the same location, and the knowledge they need is with them? What other possibilities could you explore? I believe we should always seek pathways towards the ideal. To do anything less is to sell ourselves short. Just because things are a certain way doesn’t mean they must be that way, right?
March 3rd, 2007 at 8:19 pm
[...] For me, the understanding is as important as the implementing, a point that is made very well by Tobias’s recent article. [...]
March 7th, 2007 at 12:31 am
[...] Agile Thoughts Blog Archive When is Scrum not Scrum? – I teach what I know works and what I see as being appropriate; there are slight differences in each context of course, but there are certain practices I have found to be effective, all of which differ from standard Scrum practices [...]
March 7th, 2007 at 8:20 am
Hi Tobias,
I welcome your interesting post. Developing a software solution is a complex endeavor. You have to learn aka inspect & adapt a lot. As soon as the organization and or team uses some kind of named process (e.g. Scrum, Rup, or whatever) they stop thinking about how they do their work and why, let alone improving it. Thats where the institutionalization begins and results can only be mediocre.
I think its important to stress to adhere to ‘good’ principles and learn to apply them in your current situation. I see good principles in Lean Software Development as derived from Product Developement at Toyota. These principles more or less also apply to Scrum. But you have to know to the principle and its goal in order to effectively implement it. Take the example of iteration-time. Vanilla Scrum suggest 30 days. Iteration time is in place for ‘Early Feedback’. You can make it shorter for that and other reasons. You have to learn what is a good iteration cycle for your situation. You can start with 30 days when new to this kind of approach then (most likely) shorten it. This also relates to how productive a team can be (and how productive the technology being used can be, for example Rails vs Java for Web dev can differ a factor 10). The more productive the shorter the iteration cacle should be. And then keep this stable ofcourse…
Cheers,
Michel
March 9th, 2007 at 4:33 pm
[...] Tobias Mayer has a great post on modifications to the standard Scrum that have worked for him. One of these is the idea that tasks are not measured in hours… [continued]
March 16th, 2007 at 12:21 am
[...] I’m also a little concerned that Scrum Alliance are too inflexible after reading “When is Scrum not Scrum?”. So perhaps formal training is not the way to go… [...]
March 22nd, 2007 at 4:30 pm
Tobias,
I appreciate your post and you do seem passionate about your points. However, I think you go too far by applying “what is best” as if it applies in all situations.
For example, we are using Scrum and currently are estimating in hours. The developers are starting to get a grasp on how long things take and how much of their time they spend. IMO, this approach has a lot of value and I am seeing progress. In the future, we plan to explore Story Points and other methodologies. However, we are going to apply them practically to see how well they work and adapt.
To assume there is a “magic” or “best” way of doing things is to assume that you’ve figured it all out for all organizations. It ignores the specific set of people involved in each specific organization. It ignores the specific type of product that the team is building (as mentioned in a previous post). It also ignores the business scenario of the company or group involved.
To be as direct as possible, whenever someone tells me they have figured “it” all out (mthod X is always “best”), I start going in the other direction. Obviously this applies to the ScrumAlliance topic you mentioned before, but it also applies to some of your communication of the opinions in this blog.
Once again, I appreciate you taking the time to write your opinions, but you may want to reconsider your approach to communicating them.
Best Regards.
Response: John, I think your reading of “best” is just that: your reading. In fact I only use the word “best” in one instance — “The best way to create transparency is to display everything on Big Visible Charts.” I can amend that to say “The best way I know of…” If you know of a better way, I’d be happy to hear it. In general though, I agree with you that the use of the word “best” and the idea that there is a one-size-fits all solution is to be avoided. There is no quick fix. I tried to frame this post in terms of a set of principles that I have found appropriate and effective — and they follow the core Agile principles, such as visibility, collaboration… That’s all. They may or may not work for you, but if they don’t begin to ask: why not? You may find good reasons, but on the other hand you may just find excuses.
Sometimes I talk in terms of ideals (I don’t think I do it here, but perhaps it is there implicitly). I think ideals are important in that they guide us, give us vision and goals to strive for. All of this is a journey, and it is about continuous* improvement. Do what works, certainly, but at the same time have some idea of where you want to be, otherwise you will never get there. Thanks for your comment.
* continuous improvement: this may in fact be more of a punctuated model of improvement. Sometimes a new change needs time to rest before another comes along. But this is another topic…
March 22nd, 2007 at 8:35 pm
This was interesting,
>
I feel your pain.
But I also see it has happened already: The Agile/Scrum movement factionalizing and politicizing.
I remember the good ol’ days when Object-Oriented Design was coming into vogue.
Everyone agreed that “objects” were the way to go…there were so many varities of OOD and so much discussion about which ones were right and wrong and why…
The irony was that, about the time the major minds produced a unified front and created UML, they also lost the wind in their sails, so to speak.
Here’s something I don’t see anyone recognizing:
Different people work optimally under different conditions. Some people thrive under the tight jurisdiction of a spreadsheet or scheduling tool, while others would rather submit themselves to thumbscrews and iron maidens than have to work that way.
When will we accept that people are different and the same thing does not work equally well for everyone?
In the end, our object is not to challenge anything, but to develop good software.
March 23rd, 2007 at 12:19 pm
[...] I have run CSM traning in Argentina on three previous occasions. I no longer run CSM training, as I do not believe in the certification model that the Scrum Alliance operate. [...] (from an email to the LAASD group)
April 21st, 2007 at 10:18 am
[...] Agile Thoughts » Blog Archive » When is Scrum not Scrum? (tags: SCRUM agile testing) [...]
May 12th, 2007 at 1:01 pm
[...] In When is Scrum not Scrum? Tobias Mayer challenges some of the orthodoxy of Scrum and recommends alternative practices (all of which have worked for me too); full marks from me for reminding us all that agile methods themselves need to be agile in a changing world. [...]
June 16th, 2007 at 4:51 am
[...] Other members of the Agile community can be even harsher on the spreadsheet debate including Tobias Mayer: The Scrum books, and many CSM courses promote the use of spreadsheets to track the sprint. This is really horrible. Spreadsheets hide information, and they lie. The best way to create transparency is to display everything on Big Visible Charts. The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can. [...]
June 27th, 2007 at 3:46 pm
Hi,
I am new to Agile-Scrum and I work in an digital advertising agency. The typical projects we run are all internet based, from banners campaigns and games to websites bulding (flash or HTML, sometimes with backend systems).
I have some issues that I would like to understand how to fit within the Agile scrum methodology:
1 – In some cases we have a 3-4 week turnaround in projects.
How do you calculate the lenght of a sprint?
2 – the resourcing for the projects usually means that the people working in a project will have more than one project to work on.
If we use scrum does it mean that each project memeber working in 3-4 different project will spend 2h each day(15-30 min for each project ) in morning meeting?
I wonder how would you apply a scrum methodology to this kind of projects.
Let me know if there is any book or website you can suggest for internet based projects.
Cheers
Giuseppe
July 1st, 2007 at 7:39 pm
Tobias,
I have been using all your ideas except #3 with many teams over the past couple years. The notion of tasks being either done or not (binary) is something I’m aware of and have described as an alternative that the teams may want to try. They haven’t yet, but this goes to a point I’d like to make. I think I do best as a coach if I teach folks the fundamental principles underlying agile (and lean) and then encourage them to view all practices from the various flavours of agile as things for them to pick from, as they work to better apply the fundamental principles.
So I want to chime in with a vote to say that yes the differences you have noted from ’standard’ Scrum have definitely also been applied (by myself) to more than a dozen teams on different types of projects, and they worked well. By the way my teams aren’t feeling that updating task hours is a sneaky type of micro-managing. This practice is their choice to use. I can see how some could feel that way in other circumstances though.
I’d also like to say that increasingly I have found that this approach of teaching the fundamentals and then letting the teams and their managers experiment with practices is the way to go. I do start them off with a set of practices because when they are brand new to agile they need some structure. But I make it clear that when they’ve gotten through a few successful iterations, they can and should start experimenting and use the retrospectives to evaluate the results.
There has been some mention of the programming (or engineering) practices and how they fit. I advocate for teams to get going with those but I cannot push them to do it. So I help them to understand that some of the issues they are seeing are a result of not doing enough of that. I’ve been successful getting the engineering practices going in this way.
I agree with Joe Little’s comment that telling folks they cannot start agile until they first perfect a list of technical practices can be a real non-starter. On two counts:
1. – They don’t want to be told how to do their work, even by a very knowledgeable coach
2. – You always have to “meet them where they are”, i.e. whatever their current state is, you need to be able to help them find a way to start doing some kind of incremental steps that make things better today than yesterday. That’s the creative spark that a good coach provides. It’s totally situational and cannot be packaged up as a book or training course.
I share the concern that Scrum lets teams get going without those technical practices, and the mere fact that they survive the first iteration seems to confirm for them that they are already doing all they need to. I’ve found that it works to be patient and keep giving the message that:
1. – Yes the technical practices do require an investment but are well worth it
2. – When you do enough agile testing, you can get rid of those slow approval & signoff procedures
3. – Without strong developer-written tests, the team will eventually become unable to deliver because of technical debt, dooming the team and project
4. – The biggest component of an agile team’s speed comes from the strong engineering practices
Thanks for writing up this clear description of your thoughts on how Scrum needs to evolve.
– njv,
agile coach specialising in embedded systems
April 22nd, 2008 at 12:14 pm
Wow, I am your fan already. You come across as a very pragmatic practioner of Scrum. That’s what we need more of. Keep up the good work.
May 2nd, 2008 at 9:08 am
Tobias,
I completely agree with you on all of your points mentioned above. However, if you just blog and not do anything about this, then eventually the ideals will be forgotten, I feel instead we should start our own alliance challenging the Scrum Alliance and come up with a more flexible process that will better suit challenging business environments.
I have introduced SCRUM in my organization and had many challenges and issues when following traditional SCRUM process. SCRUM cannot go alone without agile engineering practices, it has to be truly combined with TDD or some other form of Agile development to truly make it an agile process.
July 6th, 2008 at 5:44 am
A very interesting post. I am a fan of transparency and visibility. If all teams worked in a transparent way then the decisions within and across teams would be much better – because they are based on the best information you have. If things are ‘hidden away’ in spreadsheets, even by accident then how can we ever make optimal decisions. So having it up for everyone to see gets my vote every time.
The idea of tasks being either done or not (binary) is something I use all the time after reading about it in a Steve McConnell book many moons ago. It works.
With regard to Scrum Masters – I am still of the strong opinion that you need them. The team may well be self-organising but the Scrum Master comes into his/her own when they are faced with constraints that the team need to be resolved in order to progress. A good Scrum master will chase those constraints down and get them fixed allowing the team to press on with what they are good at, and most likely enjoy doing the most – developing and delivering software.
August 12th, 2008 at 1:50 am
Hi Tobias,
A great post – always useful to check what we are doing within our own team with some of the practices that other people are finding key to their SCRUM!
One of the elements we love the most is our SCRM Wall – check it out at:
http://www.buildmasters.com.au/2008/08/01/a-victory-for-scrum/
The visibility acpects of SCRUM are the thing that have helped us the most with the successes we have had on our program. Both in terms of aiding collaboration within the team and making what we do visible to the other stakeholders (who are many!).
We love SCRUM!
January 11th, 2009 at 6:08 pm
Great post.
I agree with your position. In my experiences the PO as part of the team is integral to success. Early on, we were pretty strict about product owners not speaking in stand-ups and found this caused all sorts of issues. We have external clients, and these product owners represent the customer. If we are not listening to them do we not defeat the purpose of rapid feedback cycles. When we changed this to make the account managers (product owners) a more integral part of the team with a voice, we saw immediate improvements and reduced cycle time.
October 17th, 2009 at 12:34 am
[...] also a little concerned that Scrum Alliance are too inflexible after reading “When is Scrum not Scrum?”. So perhaps formal training is not the way to [...]
May 27th, 2011 at 8:57 am
that list looks really good