Skip to main content

Scrum is Awesome! Agile is Awesome! Awesome! Awesome!

Last spring, I coached a company that wanted to get started with Scrum. I had trained a team on Scrum and accompanied them through the first few sprints. The team itself was very keen on implementing XP engineering practices, something which management did not support. My mandate ended before the project did, and so the question is, how did they do?

A big conflict between the developers and the project leader (who officially wore the ScrumMaster title, but who also had a fixed price project to deliver on time and budget) was how much effort to invest in automated testing. The customer was the P-O, so he thought quality was a great idea. The project leader wasn't so sure, he saw testing as an impediment to velocity. The team insisted, and as my mandate ended, they still had conflict on this subject.

Yesterday, I caught up with one of the developers. "How did it go?" I asked. "Scrum is awesome! Awesome! Just Awesome" he replied, repeating himself several times. (Well, the word he used was "geil," which you can translate as you see fit). So I asked "why?" His story:
Last week, I was at a trade fair to demo our product. We had just finished a sprint, so I installed the product from source based on the last build. It took 3 hours, but there were no errors. We demoed the product for three days without finding a single bug. Our PL was also demoing another product built with our traditional methods and he found bug after bug. Vindication! 
Could you have done it without Scrum? "No way!" was his answer. "Management and the customer expected to see a release every two weeks. The team had authority over engineering practices. Without that combination, our XP practices could never have taken root."


Comments

senfo said…
In a traditional agile project, it is my understanding that there is no extensive requirements-gathering stage at the beginning of a project. Instead, requirements are gathered at the beginning of each sprint. While I am a firm believer in showing frequent progress, I find it difficult to believe that anybody could successfully and/or properly architect a large-scale software project without first being able to see the big picture.

In your experience, how have you dealt with this issue?
Robert Dempsey said…
@senfo: this is a common misconception with Agile. There is a requirements gathering process up front, and even up front estimation using story points. If you don't know what you want to build in the first place, there's no way in hell your going to make any progress. With requirements, we don't get enormously in depth up front.

Typically we'll do a story carding process that starts with the who and what of the application. Then we define initial acceptance criteria. From that we can get a ballpark estimate. All of this comes from an initial vision statement of the product and the goal of what will be produced.

That scratches the surface of what agile is all about, but it'll get you going down the right road.
gustin said…
I think a key point is to call them Features, not Requirements.

Just by calling the artifacts you collect from a customer "Requirements" you are setting yourself up for a fixed scope and the customer expectation that what you collect will be delivered.

By calling them Features the customer is free to request away.

In my opinion, a true agile process accepts Features whenever the customer feels like it.

It is up to the customer and you to collaboratively prioritize Features for a certain sprint/iteration/time-frame.

~)o
gustin
Peter said…
Hi gustin,

Good point about managing expectations.

Not sure I agree whether requirements are just features though. I guess calling a nice to have feature a requirement is a bit of a misnomer. On the other hand, we should develop what is necessary ("required"), but no more.

Cheers,
Peter
gustin said…
That is true Peter, I think that is where prioritization is important.

If a feature is high priority or risky it should be done first to ensure it is in the next public release.
senfo said…
@Robert Dempsey, thank you for the clear explanation.
senfo said…
What is your take on technical staff involvement during the requirement gathering and planning stages of a project? In other words, when should technical staff be introduced to the project?
Peter said…
Hi senfo,

I ran a retrospective at a SW development house with a representative cross section of the entire company. The developers found that sales made estimates and bids without involving the dev staff. Sales found that dev was always too busy to give him an estimate.

Potential improvement: involve the team as early as possible. Evaluating an RFP to produce an estimate (and user stories if necessary) can be built into the sprint process.

Cheers,
Peter
Robert Dempsey said…
I greatly agree with Peter's last comment. If sales is out there making promises without the correct information and leaving it to dev to make up there's going to be major conflicts. Involving Dev as early as possible, if not doing the estimates up front, is a necessity. The onus is also on the dev team to give realistic expectations to sales.
sales said…
Totally agree, at the least have a representative from the technical team sit in to relate what client services or the business folks are promising and get feedback from the folks actually doing the work.

I used to be the "Director of Enterprise Architecture" at a large firm, my biggest move was filtering promises from client services. Their promises were never based in reality.
gustin said…
hey the sales reply was from me :-)

I was logged into a different gmail account.

~)o
gustin

Popular posts from this blog

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …