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.
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
After working Scrum(ish) in a previous workplace, I am trying to implement it in my new place of work for a brand new project (I am no scrum expert). We have some pre-requisites to code before we can begin working on the stories (which are being groomed in the mean time). Things like database design, api design, etc. We plan to use two week iterations and it's just not clear to me how the first one (or two) can provide something useful to the customer and "potentially shippable" if we first have to "lay down some groundwork" ? Any ideas on how to treat this?
What you are experiencing is very typical of new teams wanting to move to Scrum where they are coming from more of a traditional process. Adapting to Scrum is very, very hard and we always say this, and the reason for this is there needs to be many mindset changes.
The first change the team should understand is that when bringing a PBI (requirement) into a Sprint, it only a well defined requirement with nothing else. This means there is no designs, database schemas or API's for the requirement. The team has to do all of this in the sprint, plus build and test the requirement.
If you are new to Scrum, you most probably are squirming in your seat thinking it cannot be done. You are likely right for now, but this is where the hard work comes in ... changing the way teams work. This is hard.
Some pointers :-
Small Requirements - Most teams suffer from poor, ambiguous requirements which previously took days to design, build and test. The art is to learn to break these EPIC requirements down into smaller incremental requirements where each one builds upon the previous, but explicitly adds business value. Now, I am going to be blunt here ... this is the biggest challenge for most teams. Personally, I have been training/coaching Scrum for a number of years now have not found any feature that cannot be broken down into small requirements with an average estimate of 2-3 days to fully complete.
Team composition - The team needs people in it with all the skills necessary to design, build and test the PBI. They should not have dependencies on other people outside of the team. Having dependencies, cripples teams but it highlights to management there are not enough people with the specialised skills.
Sprint Planning - Sprint planning should be used to do high level designs and discuss how the team is going to tackle delivering each requirement. Many teams waste their sprint planning by clarifying weak requirements and debating the requirement. This is a sign of weak requirements and it should be addressed. Sprint planning is about discussing How to build/test a PBI and not What.
Coach - I would really recommend you hire an experienced contract coach/consultant to get you going and do things right. Trying to do this by yourself, just leads to a world of unnecessary pain.
Architecture - At the inception of the project, there is nothing wrong for the team and architects to spend a day or two brainstorming the macro architecture of the product and discussing the technologies to be used. However, when it comes to new requirements they are designed and adjusted into the product. This sounds hard, but with the correct software engineering patterns using SOLID principles, well defined patterns as well as strong Continuous Integration and Unit Testing. The risks of a bad architecture are eliminated. There is not question that the team should have a member in it that has the skills to design an architect the new requirements. [There is lots of evidence on the web that an evolving architecture with re-factoring results in a better application than a big upfront architecture - but that another debate]
Application Lifecycle Management - Invest in strong ALM tooling with CI, unit testing, test lab, continuous deployment. Having the right tools for the team allows you to deliver quickly, and a lack of these totally cripples you. CI with automated testing is essential for an incremental product as there is fast and constant change and you want to protect that a change does not break a previous requirement.
ScrumBut - Ken and Jeff no longer support the use of the term ScrumBut as it is perceived as elitism and often comes across as belittling. Instead it is preferred that teams are on the journey to implementing Scrum and helping them through coaching.
Welcome to your journey into Scrum, hang in there as it is very hard initially. Once you fully "get it", then you and your company will be really happy that you did.
In an ideal world, Technical pre-requisites should be factored into the estimate of each story and you should only implement "just enough" to complete the story. See "Do The Simplest Thing That Could Possibly Work"
Why do you need to design the API or the Database? Try to avoid Big Up front design. Avoid building Frameworks up front, apply YAGNI
It's hard for you to understand how you could ship something in two weeks because you have the cart before the horse; that is, your priorities are wrong. The important thing is delivering customer software - not building databases or API designs.
This is a trade of against long term productivity and you should avoid accruing too much technical debt. Many Agile methodologies would argue that up-front work like this will be wrong and therefore should be avoided to minimise waste. Lean software recommends defering decisions to the Last Responsible Moment.
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
I am a long time agile advocated but one of the things that bothers me about Agile is that a lot of agile practitioners, especially the younger ones, have thrown out or are missing a whole lot of good (non Scrum, non XP) practices. Alistair Cockburn's style of writing Use Cases springs to mind; orthogonal arrays (pairwise testing) is another.
I read mostly Agile related books and articles and work with mostly Agile folk ... is there anything I'm missing?
It might be interesting in 5-10 years time to see how maintainable these systems are when nobody wrote down why a particular decision was made and all the people involved have left.
is there anything I'm missing?
Yes, I think a lot, but only if you are interested in Softawre Development Processes.
I like this paraphrase:
Each project should be as agile as possible but not more agile.
Not every project can be agile... but I think 80%+ can.
I see Agile as "car of the year". It is very well suited for most of the people, but if you need/want something special, for example car able to speed 300KM/H or car able to carry 20 tons of goods you need something else.
There is also so many cases when one may want something else than "car of the year" that requires a book to write them down :-) I recommend you Agility and Discipline Made Easy: Practices from OpenUP and RUP. In this book you'll find many "missing parts" very well illustrated. The key to understanding is that Agility is only a (requested) property of software development process which sometimes cannot be achieved. The book describes several Key Development Principles (which are basis for RUP) and explains which level of "ceremony" and "iterativeness" follows from using them on different levels of adoption.
An example
Practice: Automate change management and change propagation
In your project you may require very advanced and strict change management and decide to "Automate change management and change propagation" by implementing custom or re-configuring existing tools and by using Change and Control Board.
Effect: This most probably increase level of "ceremony" in your project.
(...) have thrown out or are missing a whole lot of good (non Scrum, non XP) practices.
Scrum is not prescriptive, it's up to you to choose how to do things. In other words, nothing forces you to use User Stories for example (even if User Stories work for lots of teams, there is no consensus) so feel free to use (light) use-cases if you think they are more appropriate in your context. To illustrate this, Jeff Sutherland reported he would never use User Stories again for PDA device projects (they use some kind of "light specifications" in his current company). And the same applies for testing, use whatever works for you. To summarize, if you find XP not flexible enough, use something else... and inspect and adapt.
Iterative development.
In practice, agile teams may do iterations (or anything for that matter, agile is a kind of "true scotsman"), but agile processes don't require or define iterative development sufficiently.
Take RUP, for example - clumsy and bloated, it does compile a few good methods for long-term development that agile misses.
On a general note, agile is a way to steer clear of problems: how to avoid long term planning, how to keep teams small, tasks short, customers involved, etc. It works more often than not, but sometimes you have to face and solve problems: how to reach strict deadline, make big team work, achieve distant and complex goals, make customer refine requirements. That's when one needs to look beyond agile.
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 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