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.
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
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 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
What are the basic steps for Agile software development?
And how you start a new project with agile methodology?
Well OP, there isn't a single documented step-by-step guide for 'agile software development' and any procedure that aligns with the manifesto qualifies as agile
But I also understand that to get started, there has to be a 'hand-holding'/'by-the book' phase of learning. So I'd recommend that
- you take a look at your current development process. Find out the 'waste' activities that sink a lot of time and pick up an agile practice that counters/minimizes the time spent in that activity. e.g. if you're routinely fighting build issues, set up a continous integration server first and set up a stringent check-in pre-screening. Instead of changing everything such that everyone feel lost and alienated,
pick up one practice at a time
Invest about 2-3 weeks with it..get comfortable with it
check if everyone in the team feels that it is helpful. If yes, stick with it, make it part of your new process. Else discard and find and replace with another alternative remedy.
In case your entire team is new to agile, I'd recommend (in order of intensity)
Practices of an Agile Developer (Andy Hunt, Venkat S., thin book, high value-to-page ratio for newbies)
Agile Principles Practices and Patterns (Robert & Micah Martin)
Conduct weekly 'Getting Better' sessions for select practices like TDD (beck, astels, et.all), Refactoring (Fowler, Joshua K.), etc that are bound to have huge payoffs.
a month or so in.. go for the philosophical books like XP Embrace Change - Beck, Lean Books by Poppendieck, Agile S/w Development - Alistair Cockburn, Peopleware - DeMarco, Lister
I'd recommend taking a look at the books listed here
There is a screencast series called Autumn of Agile, that gives an introduction to the agile principles. There are not that many episodes out yet, but the episode plan looks like this:
Agile Values and Practices Overview
Basic OO Design Principles
Design Patterns In Action
Unit Testing Basics
Mock Objects
TDD
Project File/Folder Organization
Source Control Basics
Continuous Integration / Build Automation
Agile Project Planning Principles
Overview of Domain Driven Design Core Concepts
have a look at "Agile Software Development, Principles, Patterns, and Practices" by robert marin. there is a java and a c# version. http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445
Henrik Kniberg put together a short PDF, quick and easy to read. You could start by reading it. You'll get the answer to your question and a lot more.
What the best way is to adopt an Agile software development approach very much depends on the situation you are in. Why do you want to adopt Agile? What benefits are most important to you? What are the biggest problems you need to solve? Do you have the resources to do a disruptive all-at-once adoption? Or do you prefer to start with a longer taking, potentially more painful incremental adoption?
I'd highly recommend the book "Agile Adoption Patterns" to help you think about which is the right adoption approach for you. It might also be a good idea to get direct (on site) help from someone who is knowledgable in Agile development - someone who can observe your team, see patterns and antipatterns and contribute his experience on how to deal with them.
One of the practices that I'd always want to adapt as one of the first are iteration retrospectives. Those are vital to the adaption cycle of Agile approaches.
I recommend the article "Creating an Agile Environment" by Gregory S. Smith (http://www.methodsandtools.com/archive/archive.php?id=70) and the video "Transition To Agile Methodology In The Enterprise" (http://www.renewtek.com/index.php?page=agile-methodology-in-the-enterprise)
I'll second Ilja's recommendation for the book: http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521
I think the single most valuable piece of the book is the description of what practices to adopt first to achieve certain business values (quality, time to market, ...).
Reviews of the book: http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521
Sample Chapter: http://www.informit.com/store/product.aspx?isbn=0321514521#info8
Finally come join an Agile mailing list at groups.yahoo.com either ScrumDevelopment or AgileProjectManagement will suit your needs well.
I've read a lot of Agile books, and the one book I could truly recommend from all those is "The Art of Agile Development" by James Shore.
The best way is to hire a technically-experienced agile coach. Get somebody to work on your team that has done whatever agile method you want to adopt (scrum, xp, crystal, kanban, ... whatever) before. They're going to have to see your working circumstances - and preferably work in the environment to help. Check their references and make sure they really have used it in practice. Lots of wannabees and fakes around.
Having somebody experienced on the team makes all the difference. It's extremely difficult to adopt from just from reading a book. You're trying to change a culture and you can't do that using a checklist or an algorithm. It's a social complexity thing. You're trying to encourage emergent behaviour in a complex system.
If you can't hire an agile coach, find other people on the team or in your department or company that have experience and invite them 'round to see the team. Show them your circumstances and get their opinion.
Different teams will need different pieces of advice - it depends on lots of things including the team members, the kind of technologies you use, the type of business you work in...
Above all else, make contacts with local agilists and learn face-to-face.
You're not agile or not, you're more or less agile.
To start getting more agile from what you're already doing,
visualize more (metrics on screen, visual board, etc)
get more feedback and shorten feedback loops (CI, code metrics, bug metrics, etc)
reduce the amount of simultaneous work in progress (WIP) - i.e., reduce multi-tasking both on individual and team level
If you're able to try something new I'd recommend Kanban. It's the least prescriptive and most flexible agile tool, and you just start by visualizing your work flow and limit your WIP.