Hi Zoren,

Yes, You can. But you need a good SCRUM master and well trained team. My own experience is that the training took lots of efforts and the
SCRUM master is the key.

BR,
Jackey

posted July 8, 2008

I can't see why Scrum and agile wouldn't work in other areas than software development. It doesn't even have anything to do with software: the principles are generic enough to apply on fields, too.

And as the previous comments emphasizes the importance of a good scrum master and a cohesive, proven team, it's not worth anything if your customer (let's call it product owner from the team's point of view) is not open to play according to scrum's rules. And most customers are just like that.

posted July 8, 2008

It has been my experience that for large and/or complex "enterprise-class" projects, an Agile-only approach is never sufficient. The successful projects are typically a combination of a more formal framework (like RUP) that empowers "internal" deliverables to follow more flexible processes, like SCRUM. There are key milestones in industrial-strength projects that the flexibility (read: informality) of Agile doesn't necessarily lend itself to.

In fact, there is a model for "AUP" (Agile Unified Process), which is an example of this approach.

Links:

• http://www.ambysoft.com/unifiedprocess/agileUP.html

posted July 8, 2008

Hello Zoran,

First of all, I would like to Thank-you for putting up such a nice question. We do know things and we also practice these things, but we get to know the depth of it only when somebody asks the right question.

For your question, my answer in two words would be: "Definitely Yes".

Explanation:
Scrum Methodology of software development infact got evolved to minimize the risks, investment losses involved in the delivery of complex & big technology projects.

In other methodologies, Design, Development & Implementation of whole project is taken one go after Requirements are gathered.These monolithic approaches of software development has many dis-advantages as mentioned below:
-- Effort & Cost estimates are only as good as your past experience.
This is always challenging in case of technology projects.
-- Any flaw in design, R&D at the later stage costs very heavy on the project.
Such possibilities are very high in case of technology projects.
-- Client's Suggestions/Requirements for improvement even for small changes, will be tough & costly to implement. As those changes would have to be done accross the length & breadth of the software & will require proportionate amount of re-testing effort as well.
-- Huge investments on development will be at stake, if
-- Project hits a road-block at the later stages
-- Project is not as per Client expectations
-- Project Module integration issues could surface near implementation phase.
-- Changes in Requirements during development & implementation phase, will result in re-designing of software and will have big impact on delivery timelines & costs.
-- Delay in even one module or functionality will impact delivery timelines & costs.


Where as --


In case of Scrum, it requires little bit of extra planning, but it makes delivery of project very smooth and has many advantages.
Extra Planning is required to break-up the project requirements into small deliverable / usable software blocks divided into Sprints (defined period of say 15 to 30 days).
Advantages of application of Scrum principles are mentioned as under:
-- Risky modules and R&D related work are taken-up in the initial phases / sprints.
This ensures, identifications of road-blocks, R&D failure in the early stages, and thus saves putting of huge investments on stake.
-- Client gets the feel of the Software functionality and working sprint by sprint.
This helps in setting up of right expectations and dividing up of learning process into small bits.
-- Client's Suggestions/Requirements for improvement in one sprint, results in correction of the same in future sprints.
This saves huge effort & cost on implementation & testing, which otherwise is required in case of monolithic approach.
-- Changes in Requirements during development & implementation phase, can be handled with minimum or no impact on delivery timelines & costs.
-- Delivery timelines & costs can be tracked & managed more effectively.
This makes the delivery process transparent & helps in making everyone (not just the client) feel comfortable.



There are many other advantages of Scrum, I have just highlighted a few important ones.

For detailed explaination of Scrum pls refer this link: http://en.wikipedia.org/wiki/Scrum_(development)

Conclusion:
Considering the benefits and simplicity of the principles of Agile software development with SCRUM. It should be definetly applied to planning and delivery of projects in general. And specially for technology projects.


Best Regards,
--Manish Agrawal

posted July 8, 2008

I have also worked in an environment where Agile is applied to non software projects.

Whilst I think that some of the techniques and methodologies are appropriate, with other parts, it starts to get very blurred. For instance, what does "unit testing" mean for a non-software project?

The other big issue I saw was a massive lack of understanding. This is partly a training issue, but also largely that none of the people involved had any experience of software development and found it hard to understand the whole process when applied to non software projects. Fundamentally most of the people involved didn't understand what "Agile" meant. Lots of terminology (like "use-case" and "user-stories") was bandied about, but hardly anyone knew what they meant, and most didn't want to admit it so they made up, and used, their own definitions for these.

This meant that projects were run very badly as no-one really knew what they were supposed to be doing. In a lot of cases, the Project Leaders merely twisted Agile to beat up suppliers: "we run in 90 day cycles... that means you have to deliver EVERYTHING in 3 months. Off you go.". When faced with a large project which would take more than 3 months to deliver anything usable, they didn't know how to deal with it.

So whilst there is some value to adopting Agile/SCRUM, it has to be done with some common sense and flexibility. Not every project will fit it (not all software ones, do, so why would all non-software ones?) and not every part of these methodologies is appropriate. People need to be trained and trained very well. The process needs to be monitored for abuse or people who need further training.

Links:

• http://rbazinet.files.wordpress.com/2007/11/dilbert2666700071126.gif

posted July 9, 2008

Absolutely. In my experience, it is key to planning and delivering innovation in technology. If you are just rolling out another widget, then no. However, if you bring more than one technology together, like mobile and web, which I do often, then it is as essential as the principle itself: mobile and internet work on their own as units, bring them together and problems happen, just like compex software units of scrum and agile's origin.

posted July 11, 2008

We have been using Agile and SCRUM for several years now for software development - which is where SCRUM started life, as mechanism for controlling chaos and managing change. As for how it maps to other technologies, ie not software development, that is an interesting question. But before answering that it is worth taking a step back at what the technology in question is, and what are the failures and risks in the current methodology for managing and delivering those projects. If those risks are associated with incomplete or unknown specifications or a high probability of a change of requirements then something like SCRUM could help. If the risks are associated with, say, the physical availability of components at certain points in the development but the requirements themselves are not dynamic then it is not obvious that SCRUM offers any benefit over PRINCE 2 for example.

As mentioned in previous answers, and at the risk of stating the obvious, SCRUM and Agile will work best if you have a good SCRUM Master, the team is well trained, the management and the customer have bought into this as a method for delivering the project. This means they have to understand their roles, the constraints imposed by the sprint and the degree of autonomy they are giving the delivery teams.

One of the features of SCRUM with Agile is that the various interested parties are knitted together in the team thus shortcutting much of the conventional chains of command to give the delivery team access to expertise and business knowledge pretty much on demand. The level of commitment required by team members has to be understood at the outset of the project. However, this arrangement allows roadblocks to be addressed quickly and before they can stall the sprint or even the whole project.

Another beneficial feature is that the daily scrum should expose potential issues early and allows mitigation of the effects as soon as possible - ie highlighting additional expertise required, allowing extra resource to be brought in to deliver the sprint on schedule or allowing the customers to restrict or reduce the functionality of this sprint so that it can complete and deliver something even if not the full functionality expected.

The risks of a badly run SCRUM project are at least as high as those in any other badly run project. The problem domain, the team members and the environment are fundamental factors for the success of a SCRUM project just as they would be elsewhere. SCRUM should be considered a tool in the box and used where and when it is appropriate - I would not consider it a panacea.

posted July 13, 2008

Well, any methodology is an extension to people using it. Better ones are those that fit in rather naturally. Scrum is one of those few that minimizes fluff by the very design of it.

So going back to your original part question, Can Scrum be applied to planning? Well, it foremost depends on culture of people aiming to adopt it! Scrum planning game is fundamentally based on feedback while I'd notionally say Planning has a centralization connotation to it which is what Scrum rectifies by emprically reducing the feedback loop to Sprints that teams can choose to fitment and/or velocity observation, after having run few Sprints.

Significant planning upfront is what Scrum discourages, since such planning exercises are designed to failure. A product owner is self pressurized to include all that he wants in requirements (hence planning) before the BIG lockdown of requirements. Because if he doesn't, he knows he'll miss the train. As a result, its a industry fact that ~65% of all requirements either never make it to realization or are never used by requesters. Scrum is reverse to this planning pattern, while it accepts *everything* from Product owners, but it also mandates the prioritization attached to each. The planning game, as is called, allows the team,that knows how to deliver, decides what to deliver - picking the highest priority items and *timeboxing* them. The very idea is to deliver that will get used and is urgently required. Timeboxing allows focus, ensures delivery by definitions such as DONE. In a changing environment (show me a software team, that isn't!), shortening feedback loop of planning makes *planning* only more successful... unlike classic waterfall or glorified variances of it. Now this is not only game changing for some teams (software ones in particular), but also demands cultural and mindset shift. But what is good-to-great about Scrum is that it is designed to show results. So once such teams decide to take plunge, the short feedback loop of Scrum will let them best PLAN which methodology is good for them.

Now speaking of delivery - the remaining part of your question. There is slight subjectivity, depending on the kind of engagement you have with requester and/or his needs for delivery. I mean, do they want whiz-bang white elephant contract or you have fluidity to deliver in shorter cycles and requirements evolve as you go. The very idea of Scrum timeboxing is to mark items DONE and deliver, deliver early and fully functional units. This is something that requires crafting, and subjectivity may come from owner IF you are in client/service-delivery model. Assuming this can be crafted, I can bet my money that you will have lot happy customers adopting Scrum since they'll see deliveries quicker and functional. Happier customers will mean motivated (& self directed) and successful teams.

Process is only as good as tooling that allows practicing it. Process, Process... no Process. Such has been the impdenance mismatch with most methodolies, which promise greatness of definitions for *what needs to be done* but seperate themselves when it becomes a question of saying *how to get it done*. So if you are considering Scrum adoption, I'd recommend tooling to be a bigger role-player, having already covered culture.

I'd differ from most opinions regarding ScrumMaster being single most significant factor to success. All - please note that the very idea of Scrum is Self-Organizing team and Scrum is NOT a Manager but only a facilitator. He plays imprtant role but not most significant one in my opinion. I can say so having successfully Mastered motivated and self-organized teams in an environment thats culturally agile and having failed in another that was highly hierarchical!

I'd strongly recommend listening/viewing/reading Ken Schwaber through following links I've included. It will be worth your while, and for those that work with you today and will in future.

-- Sharad

Links:

• http://video.google.com/videoplay?docid=-7230144396191025011
• http://www.amazon.com/Agile-Project-Management-Microsoft-Professional/dp/07...
• http://www.versionone.com/VersionOneTeam.asp

posted July 13, 2008

As a billing testing manager I will try to address this issue from testing perspective as we do have teams using agile development and we do have a test team who is not agile.
A problem we have encountered with agile methodologies is the testing of the product beeing delivered. According to agile methodologies testing should be part of the scrum to ensure that every functionality which should be delivered in one itteration is actually delivered. However testing has quite a few procedures that are there to ensure quality of the software being delivered. Once you put the testers into scrum process the QA procedures will be gone and probably you will end up testing the whole software twice or more times to be sure that there are no problems which are interdependant and that by fixing one functionality the developers haven't affected the others that were considered to be done from previous itterations.
Particularly in case of very large projects, where you have many functioanlities affecting one another, you can never actually say that one functionality is done until you also finish the other. So in a sense agile is not paying much attention to software cohesiveness. So I agree with previous statements that in big projects usually you need mix of approaches.
There is another thing that should be considered and that is test driven development, but I would say that it is still development and not testing of the software quality.

posted July 15, 2008