Please login or join to subscribe to this thread
You have a good point there. And I'm afraid I don't have the answer. Though I blogged about this issue recently in my article called AINO: Agile In Name Only
Sharon you are correct that Agile goes beyond iterations. It puts people over process, self-managing teams that allow team members to choose task for an iteration. I've worked with several organizations that were moving toward Agile, some stopped at WaterScrum, doing 30 day Sprints with a traditional waterfall plan much like you described.
Some organizations think Agile is the flavor of the week. I like to think it is a lot more!
Sharon, you are right on with your comments. In my career I have seen companies implement a new process but modify it so much that what they end up with really can not be called the true process. If you pick and choose parts of SCRUM and modify other pieces because it fits in better with the way your company has always done it then don't say you are doing SCRUM. You may have something that works great for you but is not the industry standard. It gets real bad when you create new words to describe this process (Caterpillarize).
The Development department in a company I worked for was integrating Agile into its SDLC in a way that resembles what you describe. They talked about Scrum and XP and made it sound like a cafeteria plan where you pick from the different processes to create the methodology for your project. The result was an agile project within a waterfall project. Sometimes it worked pretty well - agile for the development and waterfall for the implementation, but I did not see a consistent formula for success.
As a CSM, I was concerned when they started talking about the multiple agile roles the PMO would be providing training on (developer, QA, tester, etc...) but weren't providing training for the Product Owner. Does this mean that the developer was going to write the user stories, create the product backlog, and assign story points? Kind of scary.
Agile development and Agile Project management need to go together. IT can't follow traditional practices and ignore the business, especially if it wants to succeed in Agile. For me, this creates the concern that Agile may follow the path of past processes and be set aside by companies that don't take the time to understand what it means to be agile and how to implement it correctly.
I attended a seminar several months ago where the instructor described agility as a continuum. What he said made alot of sense to me. Every team adopting agile or lean methods starts from a different place based on the skills and tools they have. Each project, each iteration of a project, they move forward (hopefully) in embracing more aspects of specific processes and philosphies.
If you are adopting a specific practice like Scrum or Extreme Programming, there are specific elements that you need to be actively doing. If you are NOT doing the core elements, then you are somewhere on the agile continuum, but you should be careful about saying you are doing that specific practice.
Using the "agile continuum" perspective, you can see how so many companies can claim agility even with a low level of adoption of specific practices.
We have been on the Agile journey for about 3 years. I arrived two years ago. I had spent most of my PM career doing traditional project management with huge teams. But along the way I had picked up or used aspects of Agile & Scrum such as short delivery cycles (~ 2 weeks), getting a product owner to prioritize the work, test along the way, defining done as when the test team says the software works, etc.
Where I am at now, we are fully vested in Scrum & Agile. Everyday, iteration & release is a journey towards getting better. In the beginning there is a struggle with just doing the basics: Release Planning, story gathering, prioritizing stories, iteration planing, retrospectives, daily standups, etc. After we started doing Scrum items, we had to tackle technical issues such as unit testing before writing code, automating testing (especially regression), continuous iteration & builds, etc.
The absolute hardest part is the cultural change. There is the change that the developers, BA/QA, and users have to go through. But then we have to help the executives & senior management team to understand that the product owner is the one who really drives whether the project meets the goals or not. Retrospectives are useful for the cultural change but only if the team implements the changes.
I'm reading this as someone interested in learning about the methodology rather than as a practitioner (Not a SCRUMmaster, not even a SCRUM-half). But I wonder whether a couple of distractions tempt organizations to claim to be "agile" when they're not:
1) It sounds cool. If the methodology was called "Indolence" (say) would it get the same reaction?
2) It is (or was?) fashionable, so we'd better claim to be doing it
3) It seems like you get away without doing all those tedious traditional project management documents. But I suppose that if you just neglect the bits of traditional project management that you find boring without putting other things in place you're not agile - heading for disaster maybe, but not agile.
What's the view from the trenches?
I work in an IT dept. that delivers products to internal customers. So here are my comments from the trenches....
1. The customers/product owners (generally VP or SVP) write a business case which describes what the project is and the benefit. The senior IT staff makes a high level estimate so the executive committee can decide whether or not to do the project and what the priority of the project will be.
2. The PM (Scrum Master) then writes up a project vision, product description, and a high level timeline.
3. At that point we start gathering stories (requirements) and story pointing them. After that the product owner prioritizes the work and we get started. This becomes our product backlog. We also product a release burn down chart.
4. At the beginning of each iteration the team will 'take on' so many stories and break them down into tasks. Each task is estimated in perfect person hours. We try to keep tasks short in time (1/2 -> 1 day long). We then create a iteration burn down chart.
Our detailed requirements, which are discovered as part of the iteration planning meeting, become test scripts. The users approve the test scripts and the developers write their code against the test scripts.
5. We use pair programming & TDD as our primary XP practices.
6. We have daily stand ups.
7. We do iteration retrospectives as part of each iteration
And we then repeat this all over again for each iteration until we finish the release.
If new stories are discovered we add them to the product backlog & let the product owner decide how to prioritize them.
The project management paperwork includes product backlog, burn down charts (which are just the giant post it notes), and any notes the Scrum Master might write up during an iteration.
Ken Schwaber's books (1) Agile Project Management with Scrum and (2) The Enterprise and Scurm books provide descriptions of roles and responsibilities and the processes.
Please login or join to reply