When I first encountered agile software development, I found it hard to understand. Okay, I might not be the brightest person you've ever met! But I'm not stupid either, I think :-)
There's a myriad of different approaches, principles, methods and terms, all of which are characterised as 'Agile'. And from my perspective, all this 'noise' makes agile development sound far harder, far more scientific, and far more confusing than it really needs to be.
For this reason, I favour the Scrum methodology. Admittedly there's a bit of jargon to learn. But otherwise Scrum provides what is fundamentally a very simple way of managing software development more effectively.
Sure, it's great to have a deep understanding of the underlying values and principles of agile development.
Sure, it's great to have a thorough understanding of why Scrum works.
Sure, it's great to know lots of case studies where Scrum has been applied and try to relate them to your own individual situation.
But, fundamentally, I believe you can implement Scrum without all this knowledge. And still find many benefits and have a very positive experience of agile development.
In these 10 posts, I outline specifically how to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...
See also:
'Implementing Scrum' PowerPoint Presentation
10 Key Principles of Agile Software Development
P.S. Click one of the icons below to join the growing community of people reading this blog by RSS or by email...
Subscribe
How To Implement Scrum In 10 Easy Steps
Subscribe to: Post Comments (Atom)
16 comments:
I'll be following this series closely. I've been using scrum for three years, but I've found it anything but easy. It's very simple to implement, but really difficult to maintain. It takes a lot of discipline and a commitment to continual re-evaluation and improvement. I no longer recommend agile methods to anyone who is not really dissatisfied with the status quo. It takes a great deal of dissatisfaction to motivate a team to develop the discipline to use any agile method consistently, and without consistency and discipline, agile methods fall apart.
BTW - really nice blog. I like your design, style, and promotion.
Kelly,
I'm very excited about this series. I just signed up for an email subscription to supplement my feed reader of your whole blog.
Scott
I get the impression that the people who fall for this SCRUM nonsense are the types who either have 1. No experience whatsoever in managing a software project and/or 2. They just want to be a consultant parasite who feeds off the industry.
If you look back at how the modern day version of SCRUM/Agile got started, it was birthed during a project that failed catastrophically; the Chrysler Comprehensive Compensation System. Am I wrong here?
Where are the success stories for SCRUM? You always find these vague stories of success written in the comments of various blogs, but it's rare to hear a product name ever mentioned. At best, the consultants will rattle off a list of companies who have bought into it all, but that's not enough. Where are the success stories on a product level? I'm talking long-term, large-budget commercial products, not some little widget you cooked up in a month.
Pardon my skepticism. I know from experience that anybody who dares to question anything about SCRUM or Agile gets the third degree from members of the cult on their turf. That's probably why you don't hear much positiveness about it all at places like Slashdot. But I'm always open to hear what you Kool-Aid drinkers have to say. Perhaps if you explained yourself better you could make a believer out of me.
Okay, here is my attempt to explain my own position more clearly.
In answer to your first point about people falling for this SCRUM nonsense having no experience or wanting to be a consultant parasite...
I have 22 years experience in software development. I have hands-on experience as a developer (and understand modern tools and technologies). I have been a Business Analyst. I have been a PRINCE2-based Project Manager. I have set up and managed Test teams. I have been CTO of a significant information services company selling software products (Windows, Web and Mobile) in the financial services sector. I am currently heading up a web development department with 80-ish people for the world's largest b2b publisher who generate in excess of £150m p.a. from online products. I am not a consultant and do not sell my services. And I have no aspirations to be one, because I like building products. I don't know everything - granted. But I do have some experience.
On to case studies...
When I arrived at my current company just 15 months ago, it was a place in chaos, with little structure to its development process, no management framework for prioritisation and so on, and with a poor reputation within the business.
In other words a development department with little process rather than a company with a heavy PRINCE2 style process or other formal methodology. We are an in-house web development department, developing our own web products, which is perhaps an important characteristic to frame my comments about agile.
In our case, implementing Scrum has transformed our department. More often than not we deliver on our promises. This was not the case before. Visibility and business engagement is good. We have a very collaborative approach. This was not the case before. Business owners have control and understanding of priorities and status. They have flexibility to change direction without fixing anything in stone up-front. This was not the case before. We deliver at least one release for all our 20-ish major web products every two weeks, and quality issues are not a major problem for us. This was not the case before. A stakeholder survey before or after shows that the large majority of people were unhappy with the department. Now I struggle to find *anyone* who is unhappy with the department.
Life before and after Scrum is not comparable. Implementing Scrum has transformed our department, from one with little credibility, to one that others all around the organisation are looking up to and seeking to follow.
Does that mean agile is right for everyone and the best approach for everything? Of course not. But it is very helpful for some. All I am seeking to do is to share information and knowledge about agile principles, and how to implement Scrum, for those people that do see value in it for them.
If that bothers you, or if you see more traditional development methods suiting your situation better, that's fine. I don't, however, see why you would assume that all other alternatives (e.g. agile methods) are rubbish or somehow just hype. They're not.
Kelly.
Hi!
Since now all the steps are there would it be possible that you created pdfs with
"10 key principles" and "How to implement Scrum in 10 easy steps" for printing/off-screen reading?
That would be great. Thanks!
Anonymous, you are wrong. :)
Your comment about a failed project is for XP, not Scrum.
You do not have to use XP programming practices to do scrum. Many people do, but many people don't
It is easy to throw stones, but unless you have actually given Scrum a real shot, you can't really comment. Many people simply do it wrong because they "think they are doing scrum" and then say.. well that didn't work...
In any case, I have followed waterfall for years and I know it doesn't work very well. ;)
from Anonymous to Anonymous
"It is easy to throw stones" and thats exactly what you are doing here, in the way you are publishing your comments; it should be good idea sharing your point of view using a constructive approach, I mean, showing the bad points and what have you tried in order to get better results.
I'm a programmer looking for more information and its not a critique about you its only I should love understand better your point.
What I have learned in my short tenure of software development, is that it all depends on the project manager (Scrum Master, if that fits who you are). Even the tried & true waterfall will fail if the management is weak. It is up to management to know when to apply the appropriate development methodology. For example, for most of my career (mostly as a developer then project lead), I was at one company, on one team. We always followed the waterfall method. It fit our needs.
Now, I'm at a completely different type of company, that has very different needs, and practice very different development methods. When I first arrived here, really up until I read this series, I thought their method of development was a bit disorganized (no one mentioned to me that they were using or attempting Scrum). And I have been having a difficult time adjusting. As I read more & more of the series, I am concluding that their development method seems to be closest to the Scrum method. And it seems to work for them, although from each of the steps, I can see where some improvement can possibly be made.
I agree with Paul, I don't think it's easy. But I don't think Scrum should be discounted in certain situations. Now as a former developer, XP is a different story. I understand the goals, but most developers can't get into "the zone" (in deep concentration & connection with the logic & code) with a backseat driver yapping in their ears. And, IMHO, when in "the zone" that's where the best work is done. But again, maybe it just takes some getting used to.
My company is basically a code-farm. We get contracts, have Software Architects layout the basic framework and then manage Scrum Teams in Europe.
Over the last year and a half Scrum has revolutionized our process.
One simple reason i think - we never realized that the quality of the process is as important as the quality of the product you product. In fact they're inter-linked.
By constant improvement in the process and the Holy Burndown graphs, we're at a point now where sprints rarely fail because we know what to look for when planning and managing each sprint.
Our company is about as diverse as it gets. We're doing everything from major products, to add-ins to ecommerce sites.
As the CEO, I can now sleep nights knowing that my clients expectations and the developers abilities and communications are balanced.
When we started we immediately lost two coders who couldn't be bothered and ended up moving one project to a different outsourcing company.
That was a bit of a shock to start off with...but these days our business is operating like glass.
I don't care whether you call it Scrum or good management...the game works when everybody plays it.
To Whom It May Concern,
My name is Donald Buresh, and I am a Ph.D. student at Northcentral University located in Prescott Valley, Arizona. The reason that I am writing to you is because I would like you to participate in an internet survey for my dissertation. The topic of my dissertation is assessing agile project management and customer satisfaction. The web site where you can find my survey is: www.assessingagilepm.com.
The questionnaire will ask you about a software development project that was recently completed within your organization. It will take you about 15 minutes to answer the questions. The questionnaire will ask you a series of questions about the project, including whether the software product was developed using agile-driven or plan-driven methods. If you do not know the answer, the questionnaire will ask you a series of three questions, and based on your responses, it is smart enough to decide what software methodology was employed. The questionnaire will then ask you other questions about the software development project. If at any time you decide not to participate in the survey, you need only exit the survey window, and your data will not be collected. When you have completed the survey, please press the appropriate button to submit your responses, and then close the survey window.
All of your responses will be anonymous and all of your data will be held in the strictest confidence. From your responses, it will not be possible to identify you or your organization. Since the data obtained from this questionnaire will be used in my doctoral dissertation, the results may possibly appear in an academic or trade publication. None of your responses will ever be revealed.
Thank you for considering to participate in this survey. If you do participate in the survey, and want to obtain a copy of my dissertation, please do not hesitate to respond to this email, and let me know. When the degree has been granted, and the dissertation has been accepted and published, I will be more than happy to send you an electronic copy. Again, thank you for your time.
Good series Kelly –
I’ve recently written a blog post What’s Product Management like a Year after Implementing Agile
about some of the ground work that was done before-hand in order to ensure implementing scrum was successful and some of the soft practical issues that we tackled and managed to ensured that scrum was a success and some of the results we have seen.
Derek
I'm implementing the Scrum Methodology for the first time. I have had difficulty understanding how requirements are handled. I understand that the Product Backlog is used to prioritize functionality, but I would think that the actual requirements of a backlog item would be completed before the Sprint Planning Meeting. Is that correct? If I'm understanding correctly, I believe the requirements should be minimal and mainly made up of use cases.
Any guidance someone can provide to me on how requirements are handled and when in the process they are actually completed, would be greatly appreciated.
Hi Shawn
Combining User Stories from eXtreme Programming with Scrum works really well.
Here is a quick tour of all the posts I've written recently on User Stories, which I think will help you:
https://agile-software-development.com/2008/04/writing-good-user-stories.html
Make each item on your product backlog a User Story, or a Theme (set of related functionality to be broken down into User Stories later).
Have the Product Owner, product manager, business analyst or whoever is appropriate in your organisation, prepare the target User Stories for the next Sprint prior to Sprint Planning.
Either do Sprint Planning in two parts of have a Pre-Planning meeting before-hand. In the first part, concentrate on the User Stories. Have someone who understands the requirements for the User Story present it to the team (whole team). Allow everyone to ask questions and clarify the requirements, making notes on the Story Card.
Once you've done this for all candidate User Stories for the Sprint, do the second part of Sprint Planning, which is to break all the User Stories into Tasks and estimate them in hours. The Product Owner need not sit in for this part of the meeting, as it's more for the team.
As well as reading the posts I've written about User Stories, read this Implementing Scrum series. In this series, I attempt to walk you through the process.
Regards
Kelly.
Kelly,
Thank you for your help. The link that you directed me to has information that will be very helpful to me as I begin to learn Scrum.
Regards
Shawn
No problem Shawn. Good luck!
Kelly.
In my, relativley limited experience of working in projects where scrum, or similar style is used, it has shown the Project Manager to be lacking in skills, and almost been a excuse for them not to 'manage', as with stages of a more tradiitonal project, overlooking things like managing risk. The 'get round a whiteboard' style is almost the reason more structured moethodologies emerged. I do understand how it could work, but frustratingly, I have found that it isn't. Must be because not everyone is adapted/used to it.
Post a Comment