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
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
Looking for work at the moment, I'm seeing a lot of places asking for Agile experience, but until I get a job with a team that is using Agile, I suspect I'll never get the experience.
Is it possible to adopt Agile methodologies with just one person?
Sort of answering my own question, there's similar questions at :-
https://stackoverflow.com/questions/1407189/can-agile-scrum-be-used-by-1-or-2-developers
(I guess I should get better at searching.)
You seem to be coming at this from a work experience point of view; if you are looking to build relevant experience to get you a job on an agile project I would probably think a little more laterally.
Firstly could you work with others, maybe on an open source project? That would be a good opportunity to try out agile methods with others who may have more experience.
Secondly, you could look at using some of the common techniques or tools, even if it's just to learn how the tools work - e.g. you could set up a continues integration server to run builds and unit tests when you check in code. If you are working on your own you won't gain much in terms of productivity by doing this but you would gain some skills and have something relevant to say to future employers which would indicate you are committed to the agile style.
Yes
Check out PXP or Personal Extreme Programming.
http://portal.acm.org/citation.cfm?id=1593127
Summary from the paper:
Personal Extreme Programming (PXP) is
a software development process for a
single person team. It is based on the
values of Extreme Programming (XP)
i.e. simplicity, communication,
feedback, and courage. It works by
keeping the important aspects of XP
and refining the values so that they
can fit in a lone programmer
situation. PXP can still be refined
and improved. It is in the tradition
of XP practitioners to vary XP to
encompass whatever works. We hope
that PXP inherits these pragmatic
roots, as well. Giving up XP tenets
like pair programming is not
necessarily a tragedy. We still
believe that following XP strictly is
a more effective way to pursue
multi-person projects. But we are also
convinced that many of the XP
practices and methods can be applied
to individual work. The PXP
approach tries to balance between the
"too heavy" and the "too light"
methodologies. PXP will inject the
right amount of rigor for the
situation without overburdening the
team with unnecessary bureaucracy.
Yes - it is possible to do many agile practices as an individual.
If you already know how to do these, you can do them as a sole developer:
test-driven development - great place to start
refactoring
continuous integration
doing the simplest thing that could possibly work (and evolving it through refactoring)
automated deployment
planning meetings (a team of one plus customer)
Things you can't do on your own:
pair programming
CRC/RRC workshops (... you'd have to talk to yourself quite a lot)
Pair programming would be hard this way :)
Let's check Agile Principles:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
You can do all of those things even while working on some personal project alone. You can use also GTD while working alone, you can develop your product through iterations, you can adopt timeboxing, you can ask some family members or friends to do usability tests with you (and this works really well).
As a conclusion, you can really get tons of Agile experiences alone. I strongly recommend you to read some books first tho, as some of principles can be easily misinterpreted.
Some aspects can be done alone: running a product backlog and using a task board come to mind. See what the secretGeek is doing.
Of course some cannot: pair programming, scrums etc...
I recently interrupted a big project. It was a medical software project. While working on it, I realized some patterns about solo programming. I want to share my experiences here:
Your software's working logic must always reflect the real world. You catch fish with fishing rod, not baseball bat; so forget it.
Always start building from the project element to which all other elements refer. That makes sense if you think that like the function in a software project which is called at most. That might be database modeling. It would be useless if you model data access layer first, before modeling database.
Never mind changing variable names. That's the most written entry in a programmer's diary; so no need to be ashamed.
Methodology changes the world. Make worth of it. Make every single logical process with a function or procedure. When project gets huge you will understand thats the best way.
If you're not designing a language compiler in assembly do not hesitate using huge procedure call chains in which one calls another and that calls another and so on. Use methods everywhere, nearly resemble every single entity with classes and be modular.
Modularity is everything. Set modularity your primary goal. Have i said it is everything meanwhile?
Last word for beginning the project. If you're building an apartment you install main entrance at last. But when using, you enter the building from entrance. Be aware.
These are some of my design principles I learned and learning day by day. I hope having been useful. Do your best.
While some Agile practices are directly targeted at more than one person teams, they are just practices, they are just a mean, not an end. I mean, Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context. So, back to the initial question, it's definitely possible to adopt Agile practices (that make sense in your context) to maximize the delivered value: continuous planning, limiting Work In Progress, Stop-the-Line culture, time boxing, high quality, just enough specifications, just enough and just in time documentation, etc, etc.
Definately. Agile is very flexible in terms of how many people are involved. Some methodologies, like Scrum, focus mostly on doing as much as possible in a limited time, like two weeks (sprints). That includes whatever you want it to. If your team requires QA, then that is part of it. As a loner, you decide what you want to include.
After the scrum sprint, you look at what you could have done differently to get more done, and move to the next one.
Some other methodologies focus more on getting features done in each iteration, say three small features developed, tested and refactored.
As you can see, there are tons of ways to apply agile to any project. You decide which aspects you want. Though obviously one integral part is doing things in small increments.
Yes
XP/TDD scales from one to one thousand. Pair programming is optional.
YES.
Agile is more of a state of mind than just a methodology of software development like waterfall.
Scrum is one of the very popular agile methodologies. You can study below aspects of scrum in detail:
Benefits of Scrum/Agile over Waterfall
How can you create better "products" with Scrum/Agile
What are the types of projects better suited for Scrum
Pros and Cons of Scrum
Scrum Rituals and why are they necessary (What advantage do they
bring)
Different roles in scrums and their responsibilities (Scrum Master,
Product Owner and Development Team)
After you have good understanding of working of scrum and its benefits, try to create a pet project.
You will have to play all the roles yourself. You can try to distinguish between what role you are playing currently by wearing different colored hats for each role.
Example:
Product owner : Think from product perspective, what should be the features in the product and why would they be important for your users etc. Then proceed with all the scrum practices.
Scrum Master: Keep checking if you are following all scrum rituals in the right sense and spirit and are you able to derive benefits out of it.
There will be limitations,example you cannot have Daily stand-up meeting, obviously because you are the only person in the project. But if you follow above, you should be good to secure a job and play your part well in the team.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have been looking at different programming methodologies: Scrum, waterfall, spiral but someone told about one called Object-Oriented. Now as far as I know that's a paradigm and not a methodology.
If it is a methodology can someone please explain how it differs from Agile or waterfall?
Well, Google found some traces of such a beast which is clearly describing a methodology-like thing:
This document aims at introducing briefly to the readers the Object Oriented Methodology (OOM). Information covered in the document includes a brief overview of the OOM, its benefits, the processes and some of the major techniques in OOM.
OOM is a new system development approach encouraging and facilitating re-use of software components. With this methodology, a computer system can be developed on a component basis which enables the effective re-use of existing components and facilitates the sharing of its components by other systems. Through the adoption of OOM, higher productivity, lower maintenance cost and better quality can be achieved.
This methodology employs international standard Unified Modeling Language (UML) from the Object Management Group (OMG). UML is a modeling standard for OO analysis and design which has been widely adopted in the IT industry.
The OOM life cycle consists of six stages. These stages are the business planning stage, the business architecture definition stage, the technical architecture definition stage, the incremental delivery planning stage, the incremental design and build stage, and the deployment stage.
But this thing didn't spread (likely) very far. Maybe you should ask your contact for some references.
Object Oriented programming is a programming technique used when writing code. This is something different from a methodology which is a way of planning, managing and implementing a software project.
see: http://en.wikipedia.org/wiki/Object-oriented_programming
Apples and oranges. OO is a way of designing code. Scrum/waterfall/spiral, etc... are about how you manage a project. They're independent of each other.
That said, you really should look into OO.
In the late 1980s and early 1990s, some authors published work (especially books) with titles and blurbs including the word "method" or "methodology" in them; these works focused on object-oriented modelling approaches, explaining in detail the modelling primitives (metamodel) that one should use to construct structural and dynamic models of systems. Their treatment of the process to follow, however, was minimal. Later, they were criticised by applying the term "methodology".
Nowadays, "methodology" is usually thought of including a process aspect, a modelling (or product) aspect, and a people aspect, at least. The modern methodologies that were built on the tradition of those 1980s-1990s works that I mentioned above are often called "object-oriented", because the modelling approaches that were used then were, in fact, object-oriented.
Actually, it is a debated topic in research circles whether the process aspect of a methodology is substantially different depending on the modelling aspect of said methodology. For example, is the process aspect of an object-oriented method very different from the process aspect of an agent-oriented one? If you think it isn't, then the term "object-oriented methodology" may make no sense to you.
Object-orientation is an entire iterative methodology, with each stage used to validate or expose holes in the previous. It covers everything from identifying ALL stakeholders, requirements elicitation from them all, documenting the requirements in Use Cases (not part of the original O-O methodology, but adopted when Jacobsen joined Booch & Rumbaugh at Rational & UML merged in his Objectory), Analysis of the requirements begins once they had been validated with text-based Use Case documents the stakeholders can understand. Analysis is still in the business problem space, not the software solution space. Architechure & System-level Design are the first steps in creating the solution space for the identified business needs. The tasks can then be broken up and Low-level Design and Programming, implementing the Design via the case hierarchy originally created during Analysis and refined in System Design in UML Case/Object diagrams is finally handed off to the coders. One hard-and-fast rule in OOADP is that the Analysis and Design artifacts are baselined BEFORE coding is allowed to begin. Any changes that the business or marketing departments want during coding MUST be submitted to a Change Control Committee, dominated by Development. They will prioritize requested changes, evaluate their effect on the canonical class hierarchy and distributed design, determine how much extra time, money, and resources each change will impose, and go back to the business & marketing people and say - "This is the cost in time, money, and resources. Are you willing to accept the cost?" If not, the change may be discarded or moved into the next release. When you design an enterprise-sized project, you only really get that one chance at creating its skeleton of the class hierarchies. The later you try to modify the systems and have to modify classes and dependencies, the more likely you are to incur extra expenses, time delays, requirement needs - and bugs. Often subtle bugs in areas you had formerly regression-tested to hell and gone.
Agile people used to refer contemptuously to the full OOADP methodology as "BDUF" (big design up front). Scrum is designed to be the antithesis of this, with 5 or 6 programmer teams working with only one Product owner who is responsible for business/customer needs, and knows only a keyhole view of all requirements, occasionally bringing in other SMEs as she identifies a need or gap. Tasks are written out as "stories" (that is a bit of a simplification - they can be any one of several forms of requirements or requirement changes) on 3x5 cards and are tackled a small group at a time, with the intention of finishing each group by the end of a 2 or 3 week "sprint." Undone tasks are put back in the backlog of stories, an analysis is done to determine the state of the piece of the project this team is responsible for, and some of the remaining stories are passed out for the next sprint. Business & marketing LOVE Agile as much as they HATED O-O because they can insert new or altered stories or Use Cases, or other forms of requirements almost to the end of the development stage. The final product keeps changing to meet what business & marketing see as quickly shifting needs and time windows (usually hysterically exaggerated). The various little stovepipes caused when you scale a project up to more than one Scrum Team are dealt with using periodic Scrums of Scrums, where the Scrum Masters of the teams get together and try to keep every team on the same tracks and determine if any teams have backlog items that block progress within another team. The bigger the project, the more bureaucracy is added to coordinating all these teams, each subtly changing their original mandate as stories are updated or new ones added.
I've worked with O-O since the original CRC cards and Wirf-Brock refinements all the way through today's iteration of UML. I even spent several years as part of a four-man team from Bell Labs, teaching O-O and C++ to AT&T development teams. I've also worked with Agile (mostly Scrum and ScrumBan, a merger of Scrum and Japanese Kanban). I have used Agile Scrum since 1998, before there was an official standard. Agile is only a partial methodology, so every project has to find other tools or methodologies to fill in the gaps. I've seen thing get REALLY ugly if the teams were not made up of 1st-level ScrumMasters and all expert developers, cross-trained in each others' skillsets. Corporations today have made rates so low, that most of the truly gifted programmers I worked with 15 or 20 years ago are doing something else for a living & getting their coding jollies working on mobile apps or open source projects. You rarely see a truly talented team. Companies hire people without the necessary 10x "rock star" skills for some of the roles, and Scrum teams can be erratically staffed. Also, the more you try to scale Scrum for larger projects, the more problematic the results and the more the department begins to shed canonical Scrum rules, looking for some hybrid that works better.
Agile is, as its early proponents first said, excellent for doing maintenance, enhancements, and smaller non-time-boxed projects and I've seen it used very effectively. However, for a corporate enterprise project that is not driven by the fickle winds of marketers and business people's hysteria about slight changes in an external market's needs or time windows, I'll take O-O every time.
Whenever I'm presented with a contract opportunity that has both Object Orientation and Agile in the same set of requirements, I run the other way.
Back in the day people believed that Object Oriented programming was going to solve world hunger. I suspect that now agile is going to do that, they've lumped them together :-)
Seriously though, although some people took object oriented design to the status of a design methodology - identify actors & behaviours in a formal way to develop the design, it is really a set of principles about how to design software. It certainly isn't a methodology for managing the development of software projects like Scrum and agile might be.
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 9 years ago.
Improve this question
What are the myths or misconceptions related to Agile?
There are lot of misconceptions related to Agile that an average new comer may fall into. What are the misconceptions in the Agile world and how do you justify that it is truly a misconception?
Update: Summary of Agile Myths
Agile doesn't allow documentation
Agile methods do not scale
Agile means no plan
TDD covers all the unit testing needs
Pair programming always results in better code
Agile is a silver bullet solution to software engineering problems (There is a silver bullet solution)
Agile doesn't need up front design
We're doing scrum so we don't need to do TDD, Refactoring Pair Programming, etc.
One can learn Agile from a book
Agile only works for trivial projects
Agile always uses "User Stories"
Read the following answers for more information about above myths and for more myths.
"Working software over comprehensive documentation" means you do not need a functional spec...
Wrong!!! It just means that you can iron out the wrinkles iteratively with the users - speaking as a vendor, you still need good documentation to assist with the QA and sign-off phases...
"We're doing Scrum - so we don't need to (pair | refactor | do TDD | ...)" Actually the Scrum founders - Ken and Jeff have been saying that all the high-productivity scrum teams implement the full range of Extreme Programming practices.
Test-driven development won't find all the bugs / isn't easy to apply to everything - so we're not going to try! - Learning TDD isn't an "all or nothing deal" and you get better at judging what to test and how to do it efficiently. I've been doing it for ten years now and I'm still finding better ways to do it and new things to consider.
I can learn all I need to apply agile methods from a book. - You need to learn by doing and that often means coaching and meeting other people that can help. Lots of things go wrong when people just try to learn it from a book.
Hysterical (and quite real) "The candidate must take direction from, and support the scrum master" (From a job spec I was sent last week...) - The scrum master isn't supposed to tell people what to do. He/She is there to facilitate - i.e. to help the team learn to sort things out themselves. It's a massive failure mode - having a scrum master that "commands" people!
Talking about "the agile methodology" - big cluelessness indicator. Firstly, talking about "agile" like it's a specific thing whereas it's a very vague umbrella terms for many different things. Secondly, use of "the" agile methodology - there are loads of them, and loads of different ways of doing many of them! Thirdly, a lot of people in the agile community got here in the backlash against the big, heavy UML-laden methods of the nineties. These people don't tend to use the word "methodology"...
You need especially talented people to develop software the agile way. Jeff Sutherland says that they considered using the "chief programmer team" model for managing teams in banks - but found they didn't have anything like enough "chiefs". Scrum is designed to get best productivity out of a lot of moderately able programmers. In fact removing one, disproportionately productive team member that doesn't want to help the others can "unblock" the mediocre team members and bring their combined productivity up to more than compensate for the super-productive former team member... That's what Jeff says anyway...
There are quite a few other XP-related ones that we came up with in an open space workshop that I led recently: http://xpday-london.editme.com/WhereHasXpGone
Myth: using Agile development practices is a silver bullet solution to software engineering problems.
Myth: Test-first development forces your project to have adequate unit testing.
Fact: Many developers get lazy, and the unit tests they write before their code are often weak and inadequate.
Myth: Pair programming always results in better code.
Fact: Programmers tend to be slightly anti-social and to have significantly different thought processes from one another. Having someone breathing down your neck as you code is very unpleasant, and the result is often a tense work atmosphere with a reduction in both code quality and quantity.
Myth: Agile means no documentation
Fact: Agile value working software more than comprehensive documentation but this doesn't mean no documentation at all. Documentation should be written just in time, and just enough. And no, Agile doesn't say one should always using user stories. Use them if, and only, if they are appropriate!
Myth: Agile means no plan
Fact: Agile does not support development without planning. Agile uses continuous planning and estimating to maximize the ROI. Actually, Agile is about scope management.
Myth: Agile means no discipline
Fact: Agile developers must be more disciplined for success.
Myth: Agile only works for trivial projects
Fact: Agile (actually Scrum here) has been used for
FDA-approved, life-critical software for x-rays and MRIs,
Financial payment applications,
24x7 with 99.99999% uptime requirements,
Multi-terabyte database applications,
etc
Myth: Agile doesn't scale
Fact: Sutherland used Scrum in groups of 500+, Cohn used Scrum in groups of 100+
Myth: "No Big Design Up Front" means no design.
Myth: Waterfall always fails.
Reality: Most of the software you're using on your agile project was developed with waterfall. Even BDUF waterfall, in many cases.
There's no real myths - but anything taken to an extreme will be wrong. An Agile project that does zero design in the hopes of "designing as it goes" will likely fail. A Waterfall project that designs everything down to the last semicolon will likely fail due to budget, time or changed user requirements.
It has been repeatedly said "Agile design methods do not scale" whereas Agile development will effectively scale to any size if implemented and thought out properly.
Myth: You need to carefully plan and schedule each sprint.
This leads you to do lots and lots of up-front planning so that you can fully plan each sprint.
This leads you to defeat agility and create a waterfall called "Agile".
The biggest myth I have seen is that people think it is better than other development processes.
It is the usual silver-bullet snake-oil that we have been seeing in this industry for years.
https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060
Myth: Agile is always a better option when compared to other alternatives.
Fact: depending on project size, requirements (particularly flexibility of such), external schedule, and customer attitude, it may not always be more productive compared to orthodox methodology.
Myth: Agile means XP and Scrum
Fact: There are other practices like OpenUP, AMDD, etc.
It's easy to know what to charge your customer. This is alway the biggest problems for us, because we don't know the scope of the project we can't give the customer a fixed price, and most customers demands a fixed price.
Great thread. While I offer nothing new in my related blog post, I do illustrate the top two reasons why Agile fails when it does fail. 1) Lack of upfront requirements (taking the 'begin coding with incomplete requirements' to an extreme) and
2) Lack of adequate unit tests (because CHANGE will happen - and unit tests are the quickest way of catching all the breaking points resulting from the CHANGE).
http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx
You're completely right that there are a lot of myths around Agile, some coming from outside, and others from inside. Here are a few more I thought of to add to the list:
"You don't need project managers or business analysts any more"
Although we're not doing BDUF and teams are self-directing, as things scale up there is still a need for people whose job is coordinating what's going on. And if you have a very complex business scenario, you may well need someone to help you make sense of it. IME, a lot of the projects that really needed PMs and BAs still need them (and those that don't need them now, probably never needed them!). But, of course, the roles of the PMs and BAs tend to be different in the Agile world, and that can make people uneasy.
"Agile can't be used for fixed price projects"
It can, but it is quite a bit harder. Especially since we all know that "fixed price" really means "fixed price, scope and time"...
"We don't do BDUF, we do it all as we go along"
The only way to work is JEDUF (Just Enough Design Up Front). Sometimes you need more, sometimes you can get by with less, but you don't do more than you need at that point.
Myth: Agile is anti-thetical to security.
Fact: This is only true, if you try to force a full-blown waterfall-style SDL (security development lifecycle) onto supposedly Agile teams. In fact, I have designed and implemented Agile-SDL variants in numerous organizations, and I can say that putting the Agile into the Security, can actually afford a higher, more robust level of security. it just takes a change of security mindset - from control to visibility and guidance.
If you don't show real value with agile, it will fail. And fail miserably as in bankrupt a company miserably. Going to agile just because it is 'agile' makes you look as silly as the CIO in this video:
http://www.youtube.com/watch?v=nvks70PD0Rs
John
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
The Mythical Man-Month is now classic, but the "Surgical Team" methodology is still interesting. What methodology most closely resembles it or has the same essence?
To summarize the Surgical Team analogy:
A surgeon understands the problem/business domain and is the expert. They are the authority when there are questions or conflict with in the team. The surgeons work between themselves when there are issues, say with design, functioning as a smaller tight team of experts. So in essence they have the knowledge of the domain, are entrusted to do they think is right, and do the actual coding? The rest of the team focuses on support, testing, documentation, and project plans are delegated tasks. Consequently the surgeon is also the most skilled/trained resource.
The answer could be project, programming, design methodologies as it seems to have implications across main methodology domains. Agile, MDA, Extreme, in sourcing development?
This question also make more sense for software that is large in a complex business domain, think air traffic control, not a COTS developer to or common utility.
One of the patterns mentioned in Organizational Patterns of Agile Software Development is titled "Three to Seven Helpers per Role"; it differs from Surgical Team in that it pays attention to every role, for example it isn't only that the surgeon 'role' that has helpers or relationships: all roles have some number of relationships.
Another pattern from the same source in named "Architect Also Implements", which may be analogous to "Surgical Team" in that the Architect in particular is (presumably) highly skilled.
In the case of a surgeon, the key actor is both the domain expert and the implementor.
I.e., he's both the software program manager (architect) and the developer.
This sort of methodology might fit certain short-burn situations: for instance, a complex operation like a live server migration or software upgrade.
For general development, however, there are a few issues with such "hero" methodologies:
Few key developers understand the problem domain to a sufficient degree, and must rely on domain experts. This is simply a function of specialization--it's tough to find kick-butt programmers who also are lawyers, doctors, accountants, or otherwise are experts in the domain the software is modeling.
Scalability is limited by the number of "surgeons" you have available.
There's a lot of down time for the other staff while they wait on instructions, since the highly-focused "doer" is also managing the team. That's ok in the OR, since you're dealing with a "zero-bug" mandate and "live software." But in this economy, a more distributed workload is more efficient, even if it results in the occasional sync problem between team members.
I'm not sure any methodology really addresses that, as it is really a matter of prioritizing the developers and bending everything to their needs, rather that being anything about how those developers actually develop their software.
If you were looking for some methodolgy that impements this, I suppose this may be bad news. I prefer to consider it good news, in that it means you can use this approach with pretty much any software development methodology.
I've worked on exactly one project that was run that way. It was so enjoyable, I nearly feel bad calling it "work". Four of us developers (with extra support personell, including the occasional extra junior code monkey) got a truly prodigous amount of code written and running properly in only 9 months. Other places I've been couldn't have done as much with a team of 20.
From the text I see the following:
Agile Like:
Small teams focused on solving specific problems
Collaboration among the surgeions
Non Agile Like:
Surgeons are the authority, driving the plan, determining the design, allocating support tasks (viewng them as subservent to coding) and doing the coding. All of those are very command and control in approach and contrary to self directing teams (vs a directed team)
There appears to be no collaboration with the business partner (let alone frequent collaboration with the busines partner)
There appears to be no prioritized product backlog, thus the surgeon picks what is important not the business partner
There appears to be no incrmental delivery (tight feedback loop)
For a waterfall project, it is suggesting to use a team of experts (surgeons) to do the planning, designing, coding etc. and allocating tasks to the "support" staff. On an agile team, testing is not treated as support but an integral part of delivery.
One can't say with certainty the methodology being advocated. However, it does appear to use the language (project plans, tasks) and assume that the waterfall approach is being followed (phases like design, coding, testing driven by a plan). Whatever methodology is being used, it one for which the few determine the work for the many.
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 9 years ago.
Improve this question
As a developer who's never worked in Agile specifically (but have worked in TDD shops), I see employers that are running Agile shops resistant to hiring someone who hasn't worked in Agile. I've run into this a few times over the past few years. Is it really that fundamental of a philosophy change? After working in TDD, I can almost make an argument for not hiring someone who's never done TDD (when working in a heavy TDD environment). Perhaps I don't understand Agile and the difference between it and TDD.
I'd actually like to work in Agile, but this seems to be one of those times where you have to have the experience to get the experience. Sure, you can do it on your own, but that doesn't qualify if you ask me. As an employer, I wouldn't really call it applicable.
Agile is not an engineering philosophy in the strict sense - TDD, Peer Programming, etc are engineering practices that Agile uses - but rather Agile is a management methodology. As such, it's more important that someone be open to the mindset that Agile demands, rather than them actually having worked in an Agile shop before. Yes, it really is a different philosophy and approach to software development. People who expect everything up front and to be told what they need to do will be very out of place in an agile environment.
When I have interviewed people, I do ask whether they have any Agile experience or knowledge, but what I really look for are some of the following:
Flexible mindset
Confidence to allow self-empowerment (critical in any agile environment)
Ability to self-assign tasks
Communication skills (top 3 most important)
Ok with vague instructions, able to self-teach
Those are some of the qualities that I think qualify someone to work in an Agile environment.
Having an understanding of what Agile's core principles are is important to understanding Agile. TDD is just a small part of Agile and more specifically XP (Extreme Programming).
First I would take a look at the Agile 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
That is, while there is value in the items on
the right, we value the items on the left more.
Then I would take a look at the SCRUM process (which is also a small part of Agile) to see what's involved there.
When I interview developers I look to see that they have an understanding of Agile and what that entails so that I can then determine if the Agile enviroment/mentality is one what they would enjoy working in.
I've hired developers into agile teams quite a few times. I'm not at all resistant to hiring a developer with no prior agile experience - they'll be slightly cheaper ;-)
However there are questions that I would ask such a candidate and there are certain responses that set off alarm bells - letting me know that this person is going to be too much work to re-train.
For instance being precious about their code and designs - a sure sign they'll be a 'mare in scrums and code reviews.
Agile is an extreme democracy - everyone is equal, but that doesn't suit everyone. Some developers just seem happier in an autocracy (tell me what to do and how to do it), monarchy (layers of middle management) or bureaucracy (specs and development by rote) - those guys just don't work in agile.
Some developers are much happier with the agile ideas, and those guys can get hired whether they have have prior agile or not.
I wouldn't worry about not knowing all the process details - good developers read up and stay current on the technologies they use, not process methodology. Since every company tailors their agile model anyway (if they don't they're doing it wrong) it really doesn't matter which variant they started with. You should know some of the terminology, but that takes a day of reading up before the interview at most.
The brand of agile that we use is composed of Project Management Practices as defined by SCRUM and Engineering Practices as defined by XP. If we are starting a new team, we will look for key roles to serve as embedded coaches for the team (an Iteration Manager/ Scrum Master Coach, Analyst Coach, Technical Coach and Testing Coach). For an existing team, given that we use pairing, we are more interested in developers that work well with others than a super programmer.
Because we using pairing, a new developer will become productive within a month with the agile engineering practices as well as the business and application domains. It provides the team with little value if a strong programmer joins the team but is unable to pair effectively.
When we interview, we ask the candidates to pair with several team members. Through pairing, we learn if the developer works well with others in a pair. In addition, we gain insight into the developer's technical skills. Because the candidate works in several pairs, we get the perspective of a number of team members.
All of our agile teams have been very effective and their projects successful. We have trained more team members to become effective with agile than we have hired experienced agile personnel.
I think it is a typical case of over-insisting on a specific skill set. Like employers who don't want someone who knows JBoss when they use BEA for their application server.
A good employer will recognize if someone is adaptable to an agile method or not. Now if they have two otherwise equal candidates in front of them, perhaps that is a bit different.
It is certainly a handy way out of having to explain other reasons that may play a more important role in the decision.
Any company or opportunity that dictates SDLC by practice instead of best fit for the current project/situation is already showing signs of it's limitations and you are probably better served continuing your job search.
Absolutely YES
There's a lot of teamwork and trusting your peers in agile and specifically in extreme programming. You need to know other people are writing decent tests and not breaking your code. Good XP developers don't want people on the team that are going to make their job much harder.
Nothing wrong with being a beginner, or somebody new to a team - but there is an element of building trust just like you would to get committer rights in open source.
These days everybody says they are agile and if you offer enough money, practically everybody with the slightest tech skill will apply for the job... so expect people to put you through a pair-programming interview.
Typically we need to know:
Can you really pair program?
Do you really know how to do TDD?
Are you just saying these things or can you demonstrate you do them?
Are you going to take the initiative or are you waiting for an old-school "project manager"-type to tell you what to do?
Stuff that will help get you hired in an agile shop:
You have tried to introduce test-driven development somewhere even if you didn't get buy-in. (It worked for me...)
You have sample code you wrote - or an open source project on which you can demonstrate test-driven development, automated builds...
You find that you've worked in teams with short release cycles ...
In your current job, can you implement some form of Agile Developement to show you are interested, have looked into it and actually have some experience? You may be able to find some non-developers to work with you. A power-user could sit with you during some coding. I'm sure no one would get in the way of using some of the Agile documentation (sprint log, burn chart).
I'd likely put forth this question: What development methodologies have you been using up to this point in your career? Do any of them encompass the spirit of Agile's ideals?
If you are someone that loves to develop via Waterfall and think it is just absolutely perfect for your world of development, then going Agile would be like going from driving a car to flying a plane or a boat. It is that fundamental a difference as you aren't going to necessarily know where you are going and deal with changes very differently than a waterfall style where each stage goes in order and there isn't any reprioritizing without jeopardizing the whole process.
When a company uses the umbrella term "Agile" in recruiting without being more specific (e.g, by asking for XP or Scrum experience), it's often a placeholder for something else they're looking for. They may want "developers who will pair program" or "developers who won't dig in their heels about not having requirement and design documents before they get started" or "developers who won't go off into a dark corner for weeks on end". The trick is to figure out what they mean.
From a narrow Silicon Valley hiring perspective, a candidate who is familiar with Agile practices (e.g., knows what XP is), has done some of them (e.g., pair programming and TDD), and who wants to work in an Agile environment gets past that hurdle.
Employers most likely stick to hiring people who are knowledgeable of agile, rather than not, because agile methodologies require that almost every team member know about the processes required by each agile methodology (SCRUM, Crystal, XP). For example, SCRUM requires that all team members, including management, understand and follow the concept of self-organization. They’ll need to understand that they won’t be dictated on their current performance: They need to instead address their issues openly (or what typically happens at the daily SCRUM). If you put someone on the team who does not know agile, they may immediately assume that since this methodology has low documentation, they can run in and code-and-fix to build a project. However, agile methodologies are process-heavy, rather than documentation-heavy.
I understand your frustration but the truth is, if you never worked in an Agile environment you are very likely to behave in counter-agile ways (so to speak), and you will likely not even understand what is it that you are doing wrong.
Since Agile is so much about work philosophy it's not something you can learn merely by reading a book, you need to have intimate understanding of how non-Agile firms operate, what issues this causes, how Agile changes that, and how you to fight the entropy (the attempts of the external world to introduce the non-agility back in).
My advice is that you first read more about Agile and start analyzing your own behavior and behavior of whatever firm you currently working at from the Agility/non-Agility perspective. Once you're able to discern the patterns, you can start trying to change your firm from within. When you fail with that, go to an Agile company and they will hire you, I promise.
Maybe they take the mentality of the barkeep in the Mos Eisley cantina (paraphrased):
We don't want your kind here.