Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Extreme Programming, Scrum and Test Driven Development definitely seem to be the most popular Agile methods at the moment. But someone recently suggested that I take a look at Feature Driven Development.
Have you ever used this method with any success? What are the advantages of using it?
FDD is what I like to think of as a wrapper methodology, in that it allows you to apply a method to manage projects at a very high level, but it still allows you to use other methodologies at a lower level.
FDD's focus is on being able to set estimates and schedules and to report on the status of a project as a whole, or at a very granular level, but it doesn't prescribe a specific method to apply in order to create the schedule, leaving that up to you to decide. The idea is that you can look at your project and state with some certainty what the project status is, whether you are on time, slipping, early and so on.
I use FDD as a means to organise my projects into manageable stages, so that I know WHEN to sign off and commence any given stage. But by itself, FDD would be pretty useless. For example, I personally use Evidence Based Scheduling and a combined BDD/TDD as elements of a development processes that are managed under a kind of FDD umbrella. Personally, I couldn't do the full XP, or SCRUMM without running into problems because my projects and team would be hindered if they were forced to engage in practices from other methodologies that don't add value to our own unique circumstances.
In any case, it is better not to fixate on any given methodology, because the needs/conditions of the company and project are likely to change regularly, and you need to be flexible in how you approach managing projects if you want them to be successful. No single methodology is a silver bullet, so the trick is to determine which methods work for you and tune your methodology to suit your individual needs. This is what being "Agile" is fundamentally about.
FDD is an older methodology. It has lot's of the ideas of other agile methodologies and misses some of them. Like Scrum it's a bit management-focussed and I think you need some elements from XP for practical implementations.
FDD is certainly interesting to look into. But just like Scrum and XP I think you have to understand the mechanics and not just implement the practices to be succesful. If you just "do FDD" or "do Scrum" you're not as adaptive as you should be.
The things I would look into if you want to understand agile would be
Scrum or FDD to understand what management can get out of agile.
XP to understand how enable agile from a technology perspective.
Crystal Clear to understand the communications aspects.
Lean Agile to get a completely different perspective on agile methodologies
I wouldn't call TDD an agile methodology by the way. It's an practice from XP but not a complete methodology per se.
Related
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 9 years ago.
Improve this question
Is there anyone who can tell me what is the difference between CMMI and Agile. I know some obvious difference, but I want to know it further. I will appreciate it a lot if someone can help me! Thanks!
CMMI is a process improvement methodology which aims to take projects or teams from level 1, "chaotic", to a higher level, ideally but not necessarily level 5, "optimising".
It consists of various capabilities, each of which is assigned to a specific level. For example, CMM level 2 requires the Project Planning capability. The levels are basically:
Chaotic, no real control.
Managed, processes at project level, mostly reactive.
Defined, processes at organisation level, proactive.
Quantitative, processes measured and controlled.
Optimising, feedback loops and continuously improving.
In my opinion, high levels of CMMI maturity are rather complex and difficult to achieve. While working for a large company doing outsourcing for a major Telco, we achieved level 5 but it was a great deal of work for continuously diminishing returns. We ended up viewing it as mostly a way to get government work and, in fact, I made a name for myself as a small projects specialist where we could still follow CMMI but not have to charge megabucks to the customer.
Agile, on the other hand, is a project management methodology focusing more on delivering what customers need rather than copious amounts of paperwork :-)
I see CMMI as one level up from Agile in that Agile itself is not a massively self-improving process.
It has improvement processes built in (such as retrospectives) but not in such a manner that the whole methodology may be turfed out if it's not performing.
In higher CMMI levels, whole chunks of project management methods (including Agile for example) can be tossed out or bought in depending on their performance and/or likely efficiencies.
Agile is a set of four main 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
—Agile Manifesto
From which dozens of software development methodologies are derived.
CMMI is a process improvement model. It's a meta-process and it's not, AFAIK, strictly related to software development.
As such it makes absolutely no sense comparing the two (a model and a set of principles). It also makes no sense asking about which maturity level is agile or even which maturity level is a specific agile methodology.
We can only talk about the specific maturity level of a particular agile software methodology implementation, e.g. "in this team we do Scrum at an optimizing maturity level".
Some great formal answers are already here, maybe this will help to understand the difference for ones who seek understanding:
On a pirate ship set of principles that keep pirates moving towards a common goal is called "pirate code of honor" - this is set of Agile principles.
But there is always one guy on a boat with navigational instruments and a map, who knows where we are now and how to guide the ship through the seas - this is CMMI.
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 6 years ago.
Improve this question
I'm basically familiar with Agile methodology and Scrum.
But what is "Lean Software Development" and "Kanban"?
Is it safe to say that Scrum, Lean and Kanban are implementations of Agile methodology? Or are Lean and Kanban different methodologies?
Do Lean and Kanban provide a skeleton/guideline (like Agile) and leave the implementation to an adjacent set of practices, like XP and Scrum?
Actually, neither Agile nor Lean have a precise definition. Both cases are rather about a set of principles and practices – in the former case, basing on Agile Manifesto, whilst the latter is based on the Toyota Production System adapted to software/IT industry.
I would say that both Lean and Agile are two flavours of the same movement in the software industry – focusing on effective delivery of products which customers actually need (this is a vast generalization though). The difference lies in the ways this goal is achieved.
With Agile, the focus is placed on establishing a well-organized process, which allows frequent delivery and enables easy adjustments to the customers` needs during the course of development. Lean focuses more on limiting "waste" (including work in progress which is considered as one of types of waste) and making the production and delivery workflow as efficient as possible.
It is often that agile and lean approaches are put into the same bucket, so you will find all sorts of mixing – Scrum + Kanban is the most significant example; refer to Scrumban for more information. Unless you talk with an orthodox it shouldn't be a problem if you label Kanban as an Agile method.
To make some order in labels: Agile and Lean are general concepts. Scrum and XP are specific implementations of Agile, while Lean Software Development and Kanban are specific implementations of Lean.
At least this is how people usually perceive them. It is definitely possible to mix different approaches, or single practices thereof, into one method. Scrum+XP or Scrum+Kanban are probably the most popular combinations.
If you want to dig deeper, I can recommend a great mini-book which compares Kanban to Scrum: "Kanban and Scrum – Making the most of both". The eBook in PDF form can be downloaded for free.
Agile expert Mary Poppendieck wrote about the principles of Lean. Find her credentials here.
Instead of me writing a lot about Kanban, please read what Swedish advisors Crisp say about it.
The practices of Lean are quite different from the hands-on, practical tasks that programming-centric XP asks you to do in your project ("Automate everything", "Have tests", "Meet daily"). Value-stream analysis could give you some new insights and conceptual tools with which to reason about business and tasks to do.
Hope this helps navigating the process-speak. Best of luck!
At the risk of irritating purists, and from a practical perspective, Lean is the highest level of abstraction whose principles and (most) practices can be applied across the entire enterprise. Your CEO will understand and buy-in to Lean. In my experience, linking Agile at the tactical level to Lean at the enterprise level makes for a much easier sell to executives.
Kanban in manufacturing is an inventory queue management technique. As applied in knowledge work (not just IT) it is a workflow visualization and queue restriction technique designed to focus teams on the smallest batch of work possible at a time to speed flow. It can be as simple as sticky notes on a whiteboard with tape lines marking off process step left to right. Or there are electronic Kanban tools available (standalone or add-ons to all of the main ALM tools)
Kanban can be easily applied as a tool for Scrum teams simply by treating the kanban board as representing your iteration. You (try to) only allow work onto the board at the beginning of the iteration and it needs to be in the done lane by the end of the iteration. And, using horizontal swimlanes, you can effectively segment the board into sections for planned work in the iteration and the (sadly inevitable) operations support work that interrupts even the most disciplined teams. This make it very clear what work was committed and what snuck into the sprint.
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
How do you prevent agile methodology with monthly sprints/iterations causing a fragmented design. For ex. take the case of design of Manhattan Streets vs Design of Boston streets. The blueprints for Manhattan Streets were designed as a whole resulting in easy manoeverability and driving. Boston streets were designed in a piece meal approach and its a nightmare getting around.
Streets are a bad analogy to use for software. Streets cannot be easily moved, rerouted, or changed without significant effort. Well-written software is an composition of orthogonal components that are easily reorganized and modified as needed.
The reason that agile development works is that both the developers and the software itself are agile. The developers respond quickly to change and the software they write is written in a manner that makes it responsive to change as well.
Refactor, refactor, refactor.
Agile development is not a mandate to throw away over-arching design. It makes a lot of sense to plan 'the big picture' - what the responsibilities of your major components are, and how they will interact, for example. In my own team, I find a reasonable compromise is to agree a broad public API up front, but defer detailed implementation decisions where possible. This allows individual developers the freedom to modify the design as the implementation evolves, while also gaining the benefit of hashing out different approaches at the design level, when changes are much cheaper. Modularity is also key - keep components specific in function and as decoupled from one another as possible. This minimises your overheads when you find you need to make changes to your implementation, and should increase the chances that individual components you write remain useful.
You can have a design phase that decides on the Streets. What buildings get built is determined in each phase.
I think that there is a tendency to do too little design/architecture in scrum projects. You can do constant refactoring but that can be alot of work, if something has not been designed. You can get into the same problem if there is an error in the design.
Use of SOLID principles would result in code which is loosely coupled & highly cohesive.
Remember design is the king.
IMHO analogies of software components with Buildings, Streets are just illogical. None of this is even remotely similar to software development or software design.
There is always a risk that Agile users will suggest adjusting the principals of agile to the situation at hand, however when this subsequently fails this leaves those who support the move to Agile open to criticism because Agile is not being adopted fully.
Fragmented design is a continuous risk with Agile because there is no value on architecture. What is needed is a methodology that uses the advantageous aspects of Agile such as Continuous Delivery but solves problems like the un-scalability of Agile. A possible approach is The Game of Thrones Methodology which does just this.
"Agile methodology" (and I assume you mean SCRUM, here) has little to do with the architecture of your design; the architecture being a property of the software or the system your creating (in the UML world you would maybe call it "artefacts").
"Agile" does not tell you anything about what kind of software you write, it can be used for any and all types of software or even easily for projects that have nothing to do with software at all.
So if you have the feeling that there is a bad software architecture in your agile project(s), then you should be looking around at what the actual cause is. Only because you are agile does not mean that everybody does what he wants without a plan, or that you need no documentation at all. While you won't specifiy every class down to the bit level before starting your work, you still will want a high-level architecture written down, even before the first sprint. Depending on your team size and constituency, you could imagine using your first sprint to even create your architecture.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I read a lot of books about what practices work well or not in software development.
And I have NEVER heard about methodoly like ITIL or CMMI in any webcast or book or blogs in the development field.
I have heard about these methodologies in my school, and to me it seems to be bureaucratic practices.
However every books on development I've read talk about collaboration, or people over documentation. (Yes, lots of agile books)
So my question is : Does methodologies like ITIL or CMMI have some impact or relation with development or the everyday life of the developer ? And do you have great books or blogs which talk about some good ideas in these metodologies I can use on a development team ?
ITIL is more focused on the infrastructure and support side and not development, so discussion of ITIL is probably more appropriate on the "IT" focused version of StackOverflow that is supposedly in development. As an aside, I take exception with calling that other site "IT" focused as IT encompasses infrastructure, support, and development in most enterprises...probably a good percentage of StackOverflow users are developers in IT departments.
I've worked with CMMI and the Team Software Process (TSP), both products of Watts Humphrey and the Carnegie Mellon Software Engineering Institute. If you are committed to continuous improvement and believe that measurement is at the heart of any continuous improvement, then you will find value in CMMI.
It is very easy to do CMMI (and TSP) wrong or in a way that alienates developers and ultimately ends up as window dressing or something that looks good on a pile of certifications. Look at the development vendors in India...they are miraculously all CMMI level 5. What they don't tell you is that was almost always one small project or team in their organization that worked hard to get the certification, but the repeatable practices are simply not there for 95% of their organization.
The focus on time tracking (clock punching), defect tracking (bug quotas), lines of code (lots of ways to "game" if you are so inclined), and making your process repeatable (making a developer feel like a cog with no freedom to innovate) turn off many developers. <-- note the jaded counter-arguments in parentheses.
The fact remains that 90% of the developers out there (few of which read StackOverflow or any technical blogs/web sites) shoot from the hip and are sorely lacking in self-awareness of where their opportunities to improve reside. For them, the process rigor and opportunity to make incremental improvements in quality through the self-awareness that repetition and measurement facilitate are valuable components of CMMI.
Done right, you get the same benefits from Agile methods like Scrum where again the focus is on repeatable iterations, learning from each iteration, and improving/narrowing in on your goal. It takes a lot of maturity and experience to lead a team in adopting either Agile methods or CMMI and get full value out of them.
Agile is sexy and CMMI is about as far from sexy as you can get, which is why you don't hear about it as much.
Agile adoption tends to be bottom-up: techies stumble upon it and recommend it to management.
ITIL/CMMI tends to be top-down: management stumbles upon it and pushes it down to techies.
That doesn't make one good and the other bad; mostly that affects the language used to describe each approach. And there are plenty of exceptions - people with experience in the trenches who are good at applying CMMI, and managers who grok agile.
Google for "agile CMMI" and you will get many hits. I prefer not to recommend one in particular, because it's an ongoing debate (i.e. some of these folks are just plain wrong).
In my view, the notion of process is certainly a useful idea to have when analyzing day-to-day software development work. The idea that there are some recurring activities, and that these activities are often organized in similar sequences, is a good entry point for asking questions that lead to improvement. You can also get some mileage by asking what is repeatable and under what conditions activities can be called managed.
The error and the excesses begin when magical thinking sets in: "If we just describe (on paper) the Perfect Process and document it accurately, people will follow it and we will get perfect software." It doesn't work that way.