As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Scrum is quite popular dev.process these days and often Project Manager suddenly gets new title (Scrum Master). However it should be not just a new title, but new habits and new paradigm. What are the bad habits of your Scrum master?
Not keeping scrums on track - letting them descend into technical discussions and a much longer meeting.
The big bad habit our Scrum Master had at first was thinking we would take care of our own impediments. That's one of the things the Scrum Master is supposed to do but she left it to us until it got unmanageable.
The other thing we've dealt with is the Scrum Master thinking they were in charge of riding the developers' backs until tasks were taken care of. This creates a bad atmosphere on the team since they're supposed to be self-managing.
To me and our team, the Scrum Master's job is to be a shield and assistant for the team, blocking impediments and doing what they can to help expedite things. Ken Schwaber's Agile Software Development with Scrum is an excellent intro to Scrum, it's what our team used and we've been pretty successful with it. There's also Agile Project Management with Scrum, which is more for the Scrum Master and Product Owner roles specifically.
Micromanaging
Exercising old-style command and control instead of facilitating a self-directed team
Focusing more on the numbers/burn-ups/backlog than on the people who make up the team
Not protecting the team from outside interference
Assigning work and asking for daily status reports instead of letting the team learn how to manage its own work.
Micromanaging the team with hyper activity
Overriding senior developers on technical decisions because "Scrum says" and "the team must vote". Totally dis-empowering senior technical people.
Trying to squeeze blood from a stone at retrospectives on issues that aren't actually issues.
Telling me the points don't matter but at each review the points are disected, analysed every 2 weeks at review. Furthermore, basing our annual bonus on our points performance.
Scrum is good but it can disregard good engineering practice and technical processes that have worked like a charm for ages.
Constantly swapping new bugs in and out of the Sprint.
There are two kinds of scrum masters:
A project manager whose title has changed because of adoption of Agile.
An exclusive scrum master who only facilitates the scrum and reports to the project manager (shusa).
The second point is preached and practiced in 'truly' Agile organizations. It is expensive but it has some merits.
Also,
A scrum master is expected to be present with the sprint team all the time (not literally). If a project manager does that, s/he would be micro-managing.
Scrum masters' role is not to manage budgets, but to put predictability around the sprint team, in terms of amount of work that the team can do.
Scrum masters should know strengths and weaknesses of team members, and facilitate inter-scrum best practice sharing.
So, my point is, if these roles are confused, the team may not do very well.
Not helping with the push-back part of the process e.g. 'these are all the stores the customer wants in this iteration so thats what we have to do'.
Constantly trying to tie actual hours worked back to story point estimates.
When I was involved in a Scrum, the Scrum master quickly developed the habit of just letting us do our own thing, and the Scrum fell back into our normal development routine.
Not being able to slot tasks within cycle appropriately (too many usually)
Not dealing well with external customers (if a certain task is too large for a single cycle, whining to the team instead of pushing back on the customer)
Making daily scrums too large of a process -- not sticking to a certain time limit (we prefer 15 min max).
I really dislike it when ex-PMs turned Scrum Master consider Scrum a way to cut back on their original (individual) obligations without investing that time back into team-work, and active stress-reduction (planning for setbacks). They just lay back and start praising themselves for the great results, whereas everyone can see the team would perform even better without their presence, at all.
In my opinion, our best Scrum masters have been developers with a large sense of responsibility, or non-PMs.
Then again, I have worked (before the world knew about Scrum) for PMs that seriously rocked. They would make great Scrum masters today, I'm sure.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Can Scrum and Project Management live together?
Can you take the best of both worlds or will combining these two methods?
A few things to consider:
Scrum is about empowering the team as opposed to command and control management style.
There is no manager in Scrum, there is a ScrumMaster which is a servant leader.
The ScrumMaster is responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.
The ScrumMaster has to remove impediments so that the team can do his job in a productive way.
Scrum implements transparency with a minimal set of practices/roles/ceremonies and there is no real paperwork.
There is no real PMO type work in Scrum, most of PMO work is (considered as) waste.
So please, keep your PM habits away :)
And during an adoption, I'd recommend to do it as in the book (Shu), don't try to adapt it for now (Ri) (see Alistair Cockburn on Shu Ha Ri). I wouldn't even consider things like Scrumban (a modified version of Scrum using Kaban for continuous flow, no more iterations) at the start.
PS: Agile methods have all been influenced by the Lean movement (most, if not all, Agile manifesto signatories had The Machine That Changed The World in their shelves). Some could say Agile methods are a transposition of lean concepts (for new product development) to software development; others would say Agile and Lean share the same theory (see for example Jeff Sutherland's article The First Scrum: Was it Scrum or Lean?). To me, there are obvious similarities (it would be easy to map the whole Toyota Production System "House" on Agile practices) and I find Lean useful to understand how Agile works and how to implement an Agile process efficiently. So I use Lean as an as an additional toolbox. But to me, Scrum has already everything to make your development process lean, if well implemented. So there is no need to mix it. Just apply it (Shu).
Yes, Scrum and the PMO can live together. They're concerned with different things though, so the edges where the two meet are going to have to give a little. There will be some conflict at the intersection. Traditional PMBOK approaches are a poor fit to product development domains like software development, but there's quite a bit of smart statistical controls in the PMBOK, and skilled project managers who can be taught to manage flow rather than schedule are precious.
Neither Scrum nor Lean nor the Toyota organization suggest that either hierarchy or directed authority are off-limits. The definition of "Self-Organization" has been significantly stretched by software developers over the years until it has become largely indistinguishable from "Self-Determination", which was never the intention.
Toyota, for example, is a very hierarchical organization that depends very much on command and control. The difference is that it's a Learning Organization and managers at Toyota are required to have mastery of the work done in their purview, and have a duty to teach that work to workers. Team members at Toyota who envision possible improvements to their work and to the process are coached by their managers through the scientific process to prove their ideas. It helps that the process isn't shaped to fit the organization, but that the organization shifts to fit a process that is continually improved.
There is always an element of command and control in any organization. Even Scrum teams are subject to it. Even if a work team itself is perfectly flat, a Product Owner can still call the ball. Software teams have seniors and juniors, and their opinions are not perfectly equal. On Lean teams, managers are expected to be masters of the work, or have, as Toyota calls it, "towering technical competence". If management isn't skilled or is too far from the work, then they'll likely make bad decisions about the work. This is the real problem, and Self-Directed Work Teams (SDWT) are a predictable result of workers seeking to insulate themselves from poor management. SDWT is not the best answer, but it might be the limit of what an organization might achieve.
And finally, Scrum is not a project management methodology - at least not from the perspective of the rigor of the PMBOK or of Lean. But then, the application of the PMBOK to software development without significant modification to account for the nature of product development is often a fool's errand, so efforts to displace the PMBOK on software teams is understandable.
At best, Scrum is a timebox planning methodology. That's still valuable if it's the thing you need, but there's nothing inherent in software work management that suggests you need timeboxes like sprints and iterations. In fact, the upwelling of interest in iteration-less approaches like Kanban and Flow-Based management are a testament to this.
In the end, there a heck of a lot of orthodoxy built up around Scrum now that wasn't introduced by Scrum's founders and leaders, and often isn't supported by them. The same can be said about how PMOs operate. Focus on the principles of flow and learning cultures and you might be able to avoid the blind alleys and myths that gather around methodologies once they've been in the mainstream for five years or so.
Has anyone tried to incorporate different ideas (scrum, six sigma, pmp, lean?)
Essentially all of the above derive from the Japanese Quality Movement in the early 1980's.
It's all about increasing quality by reducing waste, called Muda in Japan
Lean was Toyota's implementation of the Quality Philosophies
and Six Sigma was General Electric's attempt to Americanize Lean based on corporate culture of the day.
Fast forward 20 years and the IT industry have realized that all this 'lean' thinking is a great idea for building better quality software, faster. In what has been labelled Agile.
XP (extreme programming) and SCRUM are just two different implementations of Agile techniques.
Traditional management and software management is coming up against these new ways of thinking.
You can't have it all. Either your focus is on command and hierarchy (DO AS YOUR TOLD, traditional approach) vs Collaboration and working together to reduce wastes and deliver amazing things to customers (LETS DO IT TOGETHER, new model).
If you want to go deeper on this, the best approach is to read back on the original LEAN philosophies and then see how you think they can best be applied to project management. Many of best project management ideas were already considered as part of the original Lean movement, read the book 'The Toyota Way' and look into Lean that is where you can find your own answers.
Google: the seven types of muda for a start.
Your question doesn't make sense since scrum is a project management framework but here are some things to consider:
Quality is the sole responsibility of the Team; not any PM.
Not sure what you mean by "artifacts", but the few scrum has (backlog, burndown) are maintained by the PO and Team under the guidance of the ScrumMaster.
There were no "best parts" to waterfall to want to consider continuing to use once you embrace Agile.
There is no "paperwork" in scrum; its considered waste.
People try to combine things all the time. But most of the time they get the WORST of all worlds; not the best. Most mistakes teams make in implementing scrum is to make excuses for why they can't do it the right way. Then they claim it would be better to combine in something else and just make a mess of the whole thing.
I think you are going it from the wrong side.
First you need to know what kind of team you have. Then start from that knowledge and use the appropriate methodology for your team. Rather than trying to use some methodology for your team. Do a methodology for your team. That means see what they are comfortable doing and what they think would benefit all of them.
For example: Usually when a team failed using RUP, it wasn't because they didn't follow the guidelines, but because they tried to follow all of them.
Generally I think it's better if developers don't have to do paperwork and logistics. Either they are bad at it or they would be more productive doing development.
Found this useful link today, regarding The software industry has an appaling record for project delivery. Which address your exact question.
Suggest you browse around this site to get more of an idea:
http://behaviour-driven.org/SoftwareIndustryRecordOfFailure
The above the wiki for the very excellent Dan North who proposed the idea of Behaviour Driven Design (Premise: The way we think depends on the language we use and this can be applied to software also).
Well, first of all, Scrum is a project management process, so asking if Scrum and project management can coexist is like asking if water and H2O can coexist.
Second, the PMBOK defines the project manager role as having responsibility for the success of a project. Similarly, in Scrum the Product Owner is responsible for ROI, so the responsibilities of these roles are similar even if their duties are different. Scrum eschews a command-and-control management structure, emphasizing the need for self-managed and self-empowered teams that collectively make commitments and own delivering on those commitments under the principle that the people who do the work make and own the commitment... no responsibility without authority. In Scrum, the Product Owner provides guidance to the team via the product backlog prioritization and by the defined acceptance criteria for each backlog item ("Here's what I need done and here's the functionality that must exist for me to be happy"). The Product Owner also has the final say as to whether something is done or not; if the team doesn't complete a backlog item to the Product Owner's satisfaction for any reason then the Product Owner can reject the work. I'd say that makes the Product Owner a very powerful and important role in Scrum... IMO the most important role in terms of project success.
You might want to read this blogpost on selecting the Product Owner for more information on the Product Owner role.
I think the way I read your post is that the PM does 2 things:
1) Creates artifacts necessary for the business (like compliance)
2) Manage the project
As far as #2 goes, that job becomes encompassed in the PO and SM roles. The PM continuing to do it will add confusion and hurt the process.
As for #1, that is a vital role. If the business needs this, why not add the creation of these artifacts as part of the definition of "done" and add them to the team as a member who performs this specialized task. Alternatively, you could do this outside Scrum with no one even aware that it's happening, then perhaps providing those artifacts to the PO.
Scrum is project management, just not the way project managers do it, but as Scrum does it. In short, Scrum does the compelte opposite of what people think of and are tought about project management. So, from that angle, I would say no.
On the other hand, project managers can be very efficient Product Owners.
The answer is an absolute YES.
Great question by the way.
More detailed information on this can be found here: http://www.blog.pmmetrics.com/#!SCRUM-Traditional-Project-Management-Chaos-in-IT-Industry/uiho7/577428320cf2e26a9986aa33
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have proposed to use Scrum in our IT Project and our Adviser asks us if it is appropriate to us because we are still amateurs.
Is it appropriate to us Scrum even if we are amateurs?
The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:
Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.
Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.
IMHO, Scrum would be useful, because:
Once every two weeks (or every month, depending on iteration time) you'll be able to see what's working or not. And this is very valuable, specially as an "amateur" team, which is expected to be learning and finding things out much more constantly.
As amateurs, you probably won't be able to foresee everything (and that's something agile embraces)
There's more space for sharing experience (stand-up meeting, retrospective, and even planning meeting). And you share REAL experience (you must write code every week rather than just plan)
Here's the rub. I think Scrum is going to be tricky not because your team is a bunch of amateur developers but because your team is a bunch of Scrum amateurs. If you have an experienced Scrum Master, your team may reap the benefits of Scrum. Without a point person with Scrum experience, however, there's going to be overhead in learning as you go and more than likely you will get off the Scrum path quickly. At best, you will exercise a modified-Scrum approach (which isn't necessarily a bad thing.) I don't mean to sound negative or doubt your team's ability to practice Scrum, it's just best to have someone with prior Scrum experience before your team dives in. Best of luck.
Scrum, along with other agile methodologies, is not appropriate for a team that consists of students or otherwise inexperienced people.
Wikipedia has a good section on the suitability of agile software development. Barry Bohem and Richard Turner, leading software engineers, wrote a book that includes factors that can help determine if a plan-driven or agile methodology is better on a given project. One of the cases where plan-driven methodologies stands out is with junior developers, which includes students and amateurs.
Now, this doesn't mean that you need to use only a plan-driven approach. I personally think that the most important thing you can do is to find a process that works for your team. You can probably incorporate agile approaches - test driven development, continuous integration, pair programming - into a plan-driven environment that visits each lifecycle stage once.
I disagree. Scrum is better in a situation where
you can depend on the "players"; and,
the requirements might very well be changing underneath you.
A college type project generally has pretty good requirements AND the potential of flaky team members.
Further, you have to think about the purpose of even doing the project in that setting. The students need to think, plan, and discuss how things are going to work before they start diving in. Finally, scrum works best in a close knit, fast paced environment with constant communication. Which is unlikely to happen on a school assignment.
Scrum encourages a "let's just start" programming attitude which, again, is fine when you have experienced professionals working on it that through experience know the pitfalls to avoid up front.
No one says you have to fully implement SCRUM.
I can say from personal experience that SCRUM is great for 'amateurs' :) . At my 4th semester, we had to make a project in the scope of 4 months. Our group of 4 managed "semi-SCRUM" like this:
Sprints were of 2 weeks
No daily stand-up meetings (We were physically close, so we took everything on the fly)
All sprints had a headline from the start of the project. These were our milestones.
We had 2 weeks of buffer time, since we expected to delay :)
SCRUM itself is rather complex, but the ideas of sprints, part-deleverances, leadership and the likes are great. It doesn't really take more than a day for everyone to understand these concepts. For us, SCRUM made sure we had a top-notch project ready by the deadline, with tons of feedback during the development. Top grade too :)
There will always be some team dynamics to get worked out for how things like the daily stand-ups, storyboard and other Agile practices mature in a group. The big question to my mind is whether or not you have enough time to reap some of the benefits that comes after a few sprints and some rhythms have formed within a group. I would suggest at some point calling in someone more experienced with Scrum to give feedback about how to improve what you have as part of the methodology is to grow and evolve over time, IMO.
So, it is fine for you to use Scrum and see how it goes. After all, everyone has to get started somewhere and various modifications on the methodology are common to my mind. There is something to be said for how you'll walk the walk which may be easier or harder than you imagine. Good luck and I do realize this is echoing a lot of Ben's excellent answer.
I think your main problem is going to be in the estimation and tracking to the planned sprint duration. In the past, I’ve found that when resources are not intimately familiar with the coding environment they’ll be working in (this can happen with professionals adopting a new technology), it’s very easy for sprints to go off the rails. Task breakout estimation becomes guesswork and consequently it becomes very difficult to run sprints to plan.
Having said that, there are elements of Scrum which would be very useful in this environment; daily standup meetings and iterative releases are the ones that come immediately to mind. Personally, I don’t subscribe to the “do all of Scrum or you’re not doing Scrum” mantra. Be pragmatic in your approach and pick elements of the methodology which will work for you. Make sure you incorporate the continuous improvement component of doing sprint retrospectives so you can proceed with the assumption of refining and enhancing and you’ll be heading in the right direction.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been reading about the various forms and aspects of agile development, but all focused on the corporate environment. I am on a student project team at my university, and I'd like to see if some agile concepts could work in an environment other than 'everyone works full/part time'.
We do have our own project server, with Subversion for version control, and Sharepoint for documents, wiki, and action items.
Some challenges
It's hard enough to arrange a weekly meeting, daily standups are infeasable
We're our own customers for the most part (we're part of a competition, but we can't work closely with the organizers)
Not just programmers, also mechanical/electrical team members
Sharepoint's action items don't have the best interface. Are there any extensions available? Would it make sense to switch to something else (like Trac) at the expense of a unified interface for everything non-svn?
Procrastination. As students, the most natural thing to do is wait to the last minute
We have our own space, but often, it's easier to do work elsewhere, and there's no way to predict if anyone else will be there except by making explicit arrangements
Other classes (still have to pass them, so total commitment to the team is limited)
Perhaps our team could benefit from more than just agile techniques, so all suggestions are welcome.
EDIT Thanks for all the great answers. I'm going to start asking my teammates how they feel about some of these ideas, and see what they buy into. Should I link them to this question? You can edit your answer or just leave a comment to answer this secondary question.
I wouldn't try to force a full, corporate environment style Agile programming workflow onto your team, but I do think that some level of Agile methodology could be valuable. I actually think that some of your "challenges" would be mitigated somewhat by some of the Agile ideas, but would require some level of commitment from every one on the team.
For example - the daily standups/weekly meetings issue.
This doesn't have to be a large thing (and, especially in a student project case, I'd say making it smaller is better). Having a Trac site (which I'd recommend over sharepoint if you're using SVN already) with a single place (like a wiki page) to just track the standup info in one sentence can still be valuable, without taking more than 1-2 minutes per day / person.
If somebody misses a day or two here and there, it's not a big deal, but if the team agrees to doing this, it can actually help the procrastination issue (forcing people to just say "I did nothing. I'm doing nothing" has a benefit - it keeps people at least thinking about your project, which tends to reduce the amount of procrastination), as well as having people work in different locations but still stay in communication.
This is also easy enough for non-programmers to do, and can help keep the mechanical and electrical teams working together, and everybody moving forward.
That being said, I'd make sure to keep it short and sweet - Try to keep the burden to a minimum, but I still think there's value in some of the Agile programming ideas, even in a student setting.
If you ask me you're adding too much overhead to your student project. Methodologies are generally only used in corporate environments because of the need to monitor and control human resources (control isn't the right word - but I needed one stronger than co-ordinate). In a group of students, there's absolutely no need to bother with anything like that. Adhering to a methodology will only slow you down.
You have identified your challenges. Make your peers aware of them and talk about how best to deal with them. Use methodologies as a source of ideas, but don't bend to one in your situation.
You can do a weekly or bi-weekly meeting that simulate a daily. Start your meeting with the three questions:
What did you accomplish since thelast time we met?
What do you plan to do until next time?
Is there anything blocking your progress?
Note that these can also be answered by your non-programmer teammate. In the company I work for, we have multidisciplinary team using scrum (programmer and artists) and it's working well.
If you don't want to do your meeting standing up, at least don't go for comfortable sofas. This should make your meeting shorter by making people more attentive.
You should use the method to your advantage and minimize procrastination by making interim milestones. Build your task list (excel, any other spreadsheet software is fine). Split them in milestone. When comes the time to review, sit with your team and look at your product like a client do, maybe involve your teacher.
Poker planning is fun, and a nice way to clarify your what you have to do, and how you plan on doing it. Breaking down objectives into tasks will involve people from all disciplines. But only people that can do the task should evaluate it.
IMO, SharePoint and agile don't really mix well. Pick something that's more "throw-it-up-there". I'd go with something like Trac, which has great Subversion integration.
It sounds like communication and procrastination is going to be your biggest challenge. If you don't give yourself enough time to do the work and do good testing, you're not going to have a good result. This is only logical, and doesn't really have anything to do with whether you're agile or not.
In your situation, not all of the Principles behind the Agile Manifesto will be easy to apply You might be able to apply some ideas that come from the principles, specifically:
short iterations at the end of which you always have a "working" project, even if some desired features have not been implemented yet.
maximize the amount of work not done - rather than designing a grand framework that you hope will cover all the needs of the project, start small and do just what is needed as you go.
If you have milestones during your project, consider having a meeting (called a retrospective) after each milestone just to look back and see how your process worked / didn't work and how you might improve it.
On the software parts, you could consider TDD and pair programming
I would say go with SCRUM. Skip the daily meetings and instead make a private forum and require each member to check it at least once a day. Try to make your sprint retrospective and planning meetings an "in-person" event over drinks or coffee.
The whole who is doing (and has done) aspect of SCRUM is amazing once everyone gets used to doing it. The 'sprint release' concept also helps team members from 'going dark' for too long and keeps the project based in reality ("What can we do in two weeks" vs. "I have this idea I am going to start and who knows when I can finish it").
Also, if your team has more then 8 people, skip SCRUM =)
Lastly, if you have the talent and someone on your team has the means (and desire), consider TFS workgroup (I think it comes free with academic MSDNs). If you don't have someone on your team who REALLY wants to take on that burden, skip it tho.
When I was in college, I took several courses that encouraged the adoption and use of Agile practices. They were mostly a mess and although I learned a lot of from them they generally weren't the things the professor was expecting us to learn. I do agile development professionally now and love it, but here are the things I wish that I had known when I was doing agile in school:
Getting things squared with your schedule is really, really hard, which makes daily standups more important, not less. If you can't sit in the same room (very hard) then use Twitter or Yammer or just email.
A lot of Agile's benefit is simply in getting you into a rhythm. That doesn't just mean weekly meetings; it means set goals, commitment to points, and weekly deliverables. This is tough to pull off in an academic context but should go a way towards helping you with your procrastination problem.
It's tough to get used to pairing; everyone has their own computer and style of development. Try to hook a second keyboard/monitor/mouse up to your existing laptops if possible, or use screen sharing software, and standardize on an IDE. Pairing also really, really helps with procrastination but trying to do it without good tools is an awful lot of trouble.
Don't skimp on unit testing, even if you think of it as a silly, academic, one-off project. I've done projects before that I figured were too small to bother with testing and it's never failed to come back and bite me on the ass.
Sharepoint might be a bit heavyweight. Believe it or not, we still do an awful lot of things on whiteboards or with index cards. You may be your own customer but that doesn't mean you can't have stories (discrete, estimable features, basically) and goals. It's helpful to be able to visualize it: these features are planned, these are in development, these are ready for testing. If you'd like software recommendations I can give you those but I do recommend simple paper for a lot of the planning process.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
For those of you who have implemented Scrum in your organizations, what were your biggest obstacles and if you did overcome them, how?
Background: In 2006 I contracted with a large company which had adopted Scrum cold turkey just months before I arrived. The company hoped Agile/Scrum would save their huge enterprise software product. Of the hundred or more programmers there, I worked closely with a team of about a dozen for a year, observing and participating in their Agile experiment.
Summary: I believe Agile helped more than it hurt. By the end of the year, the team could consistently estimate and produce features, whereas previously their productivity was rather erratic.
Implementation: Since this was a large organization and a large product, the project ran as a "scrum of scrums." There was one scrum master for about every 15-20 developers and these teams were often divided into smaller, closely working scrums of about 6-8 people for an iteration. Teams were largely independent, could adjust their own iteration frequency (1 month down to 1 week) and were given lots of flexibility to implement agile as they saw best. The company regularly brought in Agile coaches (such as Object Mentor) to help train the scrum masters, teams, and management.
Obstacles: Plenty. Some of them related to Agile, some not. In no particular order, here are some lessons learned:
The product backlog was revised way too often in the beginning. Eventually, the team and management took several days to go over all the features, estimate them, and prioritize them. It was a big hit, but it helped tremendously. Lesson learned: get your product backlog in order early and keep it maintained. Product owners must have a clear idea of what they want.
We lost time experimenting and dealing with fads and hype. When you start, you have no way of knowing if you're doing things correctly. There's temptation to constantly fiddle with the agile process taking the focus away from the product. Lesson learned: having an experienced Agile coach does help reduce this learning curve. There should always be someone pushing back on any experimentation. Limit the number of "spikes".
A good scrum master is invaluable. Certainly in the beginning, it's a full-time position.
It takes time. It took several months before the team started to be comfortable with the process.
Pick your battles. Some programmers will be understandably skeptical and others will outright dislike and flight the change. Allow for some flexibility. For example, enforce the use of a product backlog and iteration schedule, but don't require everyone use note cards. Be particularly sensitive to introducing tools and programming methodologies such as pair programming or test first development.
Finally, keep communication open and manage expectations.
Good luck!
While working as a Delphi developer a few years ago, I managed to get Scrum adopted by my development team for a time.
The whole process worked very well for us - having the team estimate prioritized tasks on a backlog gave us meaningful timeframes to target, and the whole "Managements job is to remove impediments" was great.
The biggest problem was that the process was always perceived - and referred to - as "Bevan's good idea".
While the team appreciated the value we gained, and were happy to continue with Scrum, the Team didn't take the scrum methodology on board as their own. After a while, I got tired of "pushing" and we "fell out" of following the Scrum approach.
Lesson: Make sure the team takes Scrum on board and owns the approach.
We do mostly scrum projects at the customer site. Hardest part in my experience is finding a good product owner in the customer organization:
Too many people think they should be the product owner,
The product owner has a hard time following the pace of the team
Product owner has a hard time getting all the detailed information the team needs
Moving items down the product backlog to add something with a higher priority is difficult
etc.
Training internal teams to use scrums is doable, bringing in your own scrum master is doable, but a good product owner should be part of the client organization. It's harder to train this external person.
Having a proxy product owner, who works together with the customer product owner does help a lot.
I moved from a company that adopted Agile to the tee to another company which follows the traditional methodologies.
Perhaps the biggest difference I have seen is that the second company struggles to prioritize. There is so much work on each person's plate that they fail to deliver on time. IMO, Agile brings about some transparency to the situation and lets the team as a whole prioritize.
A scrum master in the Agile world would take care of fire-fighting and be the voice of the (sprint) team. In fact, in the first company (where we had a separate scrum master and program manager), the scrum master would fight it out with the program manager when the latter makes false promises to the management. Meaning, the scrum master knows how much a team can produce/deliver after a few sprints, which helps her nail down on the predictability of a team.
I also noticed that the R&D resources have a sense of accomplishment at the end of each cycle, and are looking forward to the next one. But then, a good project manager could get this done in traditional scenarios as well.
The biggest issue, as already stated, that I too have experienced is the lack of buy in. It is very difficult to get people to truly become vested in the process.
The other issue, which is also one that directly contributes to the above issue, and also in a large part one of the founding causes of Agile is the lack of management to stick to the outlines of the manifesto of Agile.
In Scrum, Lean, or whatever version of Agile you are working with one cannot break from the manifesto points. If a process is being used to break away from those priorities then most likely the management is screwing up and the buy in will fall apart. The manifesto MUST be followed:
Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Some scenarios might be when a gantt chart appears from one of the above processes for whatever reason. Gantt charts can be useful, but if all of a sudden a developer is reviewing a gantt chart with management, the last point is broken. Responding to change has slowed because encouragement of the plan is being favored over change. Instead a board with stickies should be used, simplify what is on the board with only the current working items and back burner items. This makes changes easy. Once anything is solidified in a "tool" it slows responding to changes. Sure, management needs to record and track things in some ways, but pushing that onto development only slows the responding to change, and pushing tools onto developers (unless they want them for development and can utilize them appropriately) messes up the first point, of the individuals over tools and process.
In another way, don't stop development for the purpose of writing comprehensive documentation. Unless you only have a single developer, then someone should take the documentation load autonomously from the development role. Pushing these things together drastically slows development and for periods of time, can shut down any effort to actually get working software.
The last point, is to always, ALWAYS stay in contact in some way with the customer or prospective customer. Talk to them regularly about what they want. Talk to them daily and show them as much as you can of UI, or even data flow work. Anything that they would understand they should see. Talk to them, educate them about the architecture and ideas going into the application and never forget that you are building the application for them.
Summary:
Biggest issue is buy in. Second is management sticking to the manifesto guidelines.
If you can mitigate these two risks, you should be good to go. Anything else is cakewalk after getting buy in and getting management to understand that they'll need to be truly strong, and non-micro management managers. Specifically, managers might even need to become leads, or fill a different style of role.
...hope I didn't stray off point too much. :)
I have been running Scrum in several projects. The biggest problem, as I see it, is that not everybody in the organization is into the process. Everybody needs to be committed. Not only the team of developers. Often the managers are the persons that initialize the process and expect that things will change to the better without them doing anything.
My suggestion is that you run a workshop with the whole organization so everybody knows how the process works. Not only the developers. It's essential that you have a person that is really into the process. A person that can answer questions the team and organization have. A mentor.
Being agile is about welcoming change. You should not let the process gets in the way of sense. Do things that works for your organization, but you should try out the whole process before throwing something out.
We implemented Agile (set of SCRUM - management and XP - engineering practice) in an environment that was waterfall with large projects in an environment that was heavily integrated. The waterfall police were everywhere. As you can imagine, many projects failed. Having done Agile at a previous employer, we received permission to trial agile for the project.
Internal to the team, we used the Agile practice. Externally, we wrapped the agile practices with waterfall processes meaning primarily reporting. Thus, we looked from the outside like a waterfall project. However, there was a big difference, internally we were using agile and consequently we delivered, on time, within budget with high quality.
The critical success factors were embedded coaches (Iteration Manager Coach, Dev Lead Coach, Test Lead Coach and a Solution Analyst Coach). Securing commitment from dependent system in advance (required that we look ahead to identify depend systems and the work required from those systems) was a must in a heavily integrated environment. Prior to starting, we immersed the technical and business members of the team in an agile boot camp. This ensured that the key players (product owner and technical team) knew there roles and could execute effectively. Finally, the wrapping of the project with waterfall reporting enabled us to tie into all the existing reporting structure in the enterprise.
The net result is that the company is now moving waterfall projects to agile. This is all possible only because we have been able to deliver high quality software at a sustainable pace.
Where I work has been using Scrum for a while now but it seems to have gone through a few phases. In terms of obstacles, one part is to prevent putting in too much change at once and just introduce things slowly,e.g. put in a daily standup one week, a couple weeks later put in a story board, a couple weeks later bring in pair programming. This allows for the various tweaks that will happen to work and if the changes improve things then this can help build up some good momentum. Another point is to make sure that if there should be changes in how something is done that the person being corrected isn't belittled or mocked. At times this may mean that you interrupt someone or that you bring in a "Can we get back to basics?" or something similar to try to put things back on track rather than just yelling at someone or doing something else that is counterproductive.
Bringing in consultants was one of the best things done around here, IMO. Now, these guys came in to help evolve how development was done here. Bringing in pair programming, TDD, concepts like broken windows, organizing project folders, and bringing in mocking for tests, were all excellent additions that while we may have gotten there on our own, it may have taken a long time which wouldn't work out so well.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
If you had to make a case to a business about adopting or moving to an agile development methodology (like SCRUM or XP etc) what case would you make (how do you sell the concept)?
e.g.
How would you describe the concepts and benefits to a non-technical person?
If you have successfully done so, what was the winning argument/case/rationale?
Edit: The reason I ask is that a friend of mine (he is the solution architect at a firm) is currently trying to decide how to approach his management about exactly this topic, and I've given him what I can in terms of suggestions. Curious especially to hear from those who have successfully made a case to move to an agile-aligned methdology.
My Case: The organization thrashed around for a good 2 years and failed before finally jumping onto the agile bandwagon... there is no better alternative (as of now... personal opinion) to produce quality software at the rate at which the world changes. You cannot afford to make things the old way anymore. Some learn the hard way.
Elephant in the room: Just because an idea is good doesn't mean it will be accepted.
Logical Arguments:
Feedback loop is short. Customers can see working software at the end of each month/iteration, play with it... refine and tweak to taste. No more developers sucking dough for a year and coming back with an drunken elephant for the customer waiting for a horse.
You don't need to set everything in stone (the holy SRS) before development gets to work. You CAN change your mind to reflect change in business priorities/market conditions as time goes on.. (developers won't throw a tantrum).
Better communication: No more 'This isn't what I asked for!' when nothing can be done to salvage the ship. Dev talk to real customers in real time to clarify doubts and verify that they build the right thing. The onus is squarely on customer + development to ensure that the right product is built... by talking to each other.. all the time.
Human process: Agile recognizes the fact that software is made by people for other people. The practices facilitate interaction, learning and respect among the team. Better morale is also observed
Following practices like TDD, Automated tests, Pair Programming, etc. lead to better Quality products. Time traditionally spent in the 'bug-fixing-and-churning' phase at the end of the project is minimized.
Ease of maintenance. Regression testing is a SNAP! The systems built are amenable/easier to change/extensions.. if done right. The developers value simplicity vs over-engineering as second nature. Developers are not afraid to 'go in there and change it' vs 'I'm not touching that twisted thing.. last time's scars haven't healed yet.'
More realistic chance of meeting deadlines due to developer buy-in. Estimates are revised based on actual team velocity rather than gut-estimates of the person tasked with creating the chart/mpp/plan
Visible Progress - Big visible charts (burndowns, etc.) tell you exactly what's happening in the project without having to mine it out of secretive/reluctant/very busy people. Issues are In-your-face and can't be ignored/hidden for long. Development doesn't have to context switch to 'progress reporting' mode for a day a week to generate information for management... Easy to gather metrics that developers don't seem to mind.
Did I break the char limit?:)
Non-technical people are interested in projects done on time and within budget with good quality and which would satisfy their requirements at the time of the delivery. You should focus on how Agile helps to deliver those qualities.
It's sometimes quite difficult to sell Agile to a non-technical person for two reasons:
The concept of not trying to plan 100% ahead is not really intuitive
Quite a lot of people claim that they use Agile, fail miserably to deliver anything and give the great SDP a bad name
Talk about Agile process ability to handle changes.
It's usually easier if you work with the customer who already work with you. You could easily show them for example all of the change requests accumulated over the time and show how they affected the schedule and the costs of the project. You could then go into explaining how Agile process will help handling such cases.
Along the same line you could take the initial estimations done on a 'waterfall project' and compare them with real-life results.
I would also talk about the Agile approach to quality. Testing during iterations increase the quality considerably. Short iterations with immediate feedback are great help too, mention them.
Things that sell it well is:
Tangible product after each iteration that can be tested, played with, and released. (Good for a product owner who likes to see what his/her money buys)
It brings transparency to the development process, especially during daily stand-ups and so cuts down on functionality duplication and confusion
Having a demonstration after each sprint educates fellow employees about what direction the product is heading, what is available after the development work and gets people talking and thinking about what would make it even better
Development estimations can be made to a reasonable accuracy after a dozen sprints. At least after a few modifications to focus factors.
Improves developer buy-in as they get to own a particular functionality
Cost of product changes when using Agile tends to be much smaller than when using a waterfall methodology
Great for smallish development teams, but require buy-in from the development team.
It's almost impossible to introduce a new methodology without specifically referring to problems with the old methodology and how the new methodology is going to fix those problems.
In reality, you probably need to offer a bunch of choices, and then end with recommending your favourite. Come prepared with a good explanation of why it is your favourite, and with a really good knowledge of the weaknesses of your chosen methodology.
And make sure that you're not confusing the strength of your feeling for the strength of your argument, and that you're not trying to pass off personal value choices and cultural attachments as objective technical evaluations. Your colleagues aren't stupid - they will know if you're doing this, and they'll quickly flip the bozo bit on you.
If you want to get philosophical about this, communication doesn't actually depend on eloquence, rhetoric, or articulation, but on the emotional context in which the message is being heard. People can only hear you when they are moving towards you, not when your words are pursuing them.
In my experience, the one thing that instantly sells Scrum to non-technical management is the burndown chart. The idea that there is a paper chart - available for all to see and readily understand - that shows daily progress is an instant winner. It clearly shows very early on whether a project is on schedule.
Since the backlog, sprints, daily scrum etc are all required to make the burndown chart work, sell the idea of the burndown chart first, then explain there is a need for the rest of Scrum and finally point out that it is viable to perform a three week trial of the process with minimum impact to the schedule.
I think the number one selling point to the business is that they decide what you are going to work on, so they will be setting the priorities.
My boos, a non-technical person, usually prefer to listem about how a new methodology will improve productivity of the team. So, our aproach to introduce SCRUM, as a management methodology, focused on gains at progress visibility, better communication and sooner feedbacks.
All the other gains, as a fact of matters, seens intangible for people like my boss.
From what I have read and heard the term Agile seems to get a bad rap and scares people. From a business perspective I think what it boils down to is how can I provide business value in a more responsive way. Agile is a method of supporting the concept of delivering business value quickly.
Instead of discussing it in technical terms I would suggest your friend discuss it in business terms and state that he has some ideas that could help deliver business value to his end customers more quickly.
I would not reccomend he discuss XP or agile as the methods but instead introduce short, deliverable focused meetings (ie SCRUM) and then attempt to grow it from there. I feel if you tell the business that you can get them what they want faster and in a more predictible fashion and you deliver on that statement you will get buy-in to the practices that get you there.