As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is anyone using Kanban (or scrumban) for the agile management practices? What is your experience with Kanban? How does it work in large complex environments with dependencies on waterfall projects?
I know the BBC use it quite extensively. See David Joyce's blog for more details
http://leanandkanban.wordpress.com/
He has a quite hefty slide deck in there to sift through.
I think the thing to remember about Lean thinking is that you must consider the value stream as a whole. Whilst you can super optimise the development team using techniques such as Kanban, it is more important to incorporate both up stream (Management/Analysis) and downstream (QA/deployment/support) to fully reap the rewards.
Therefore, to ask how does this fit into a Waterfall or complex process (beyond your personal effect), is not quite the right question. What is a more important question is to ask how can I begin to effect the entire value stream. I know this sounds like the beginning of religious Lean zealotry, but it is how you will realise the true value of a lean process.
For example, consider the following scenario for a typical project:
Analysis time: 18 months
Dev time: 9 months
QA & release time: 4 months
Customer adoption and rework: 12 months
Total: 43 months
If by applying Lean to the development process you improve by 100%, ie a development time of 4.5 months, bringing a new total of 38.5 months. You have then only increased the total value stream by just over 10%... insignificant!!
You need to begin to fight the fight and take the Lean thinking to upper management and demonstrate where real success lies... which is in the re-design of the entire process.
Remember Lean is NOT a development process, it can be applied to every aspect of the business.
Some interesting books on how to take this discussion beyond the the development team include;
Lean Thinking
Beyond Budgeting
Throughput Accounting
The Toyota Way
Freedom from Command & Control
Lean Product & Process Development
Implementing Lean Software Development: From concept to cash
Firstly, it is important to realize the problems that Kanban in software development tries to solve:
Multi-tasking / Overload of work.
Kanban addresses these by its
Just-in-time and Queue systems. There
is sufficient in the queue to keep
everyone busy, but not overloaded
(this comes with practice with
estimation and efficient velocity
monitoring). And JIT ensures that
people do not have to multi-task and
hence loose productivity.
Unpredictable downstream releases. If you work in a large software organization, the piece you are developing might just be one in a large juxtaposition of software. Hence, there might be downstream teams that might wait for your feature. Kanban's queue system along with its time-boxed delivery schedules ensure that there is a certain amount of predictability in the releases.
Mostly, other agile practices also attempt to solve similar problems with different techniques.
large complex environments with dependencies on waterfall projects
This makes it hard if you have a dependency on a project that does not follow agile as then your input queue will not be predictable. If a non-agile project depends on you, the problem might be lesser - but you might end up producing more than can be consumed ('muda' in lean terminology). So, ideally you would want all dependant projects at least following some agile practices, if not kanban itself.
A nice article on Kanban, Flow and Cadence can be found here.
Is anyone using Kanban (or scrumban) for the agile management practices?
Yes, I'm using :-)
How does it work in large complex environments with dependencies on waterfall projects?
In our environment we have >500 developers, so it is quite large. My team was the first, which used Kanban, mainly for maintenance work, and now for development. Our daily work was very hard, because the other depending teams were following classic development and management techniques, and they liked (they still do) to push the work and Kanban is about pull.
Our approach was to communicate as much as possible make our work transparent, but due to the reluctance of the environment we were focusing on our internal work. The WIP limit helped us stay focused, and with the visualize workflow we knew who is doing what at the moment.
Our throughput before Kanban was 90% (in other words, when 10 items came in, we delivered only 9), and after Kanban we had 100.4% and it was increasing. As an additional result, other teams started to came by and ask about Kanban, because they liked our results, and wanted to implement their own Kanban system. At the moment I know about 5 teams, which started Kanban in our organization.
HTH,
Zsolt
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been reading about the various forms and aspects of agile development, but all focused on the corporate environment. I am on a student project team at my university, and I'd like to see if some agile concepts could work in an environment other than 'everyone works full/part time'.
We do have our own project server, with Subversion for version control, and Sharepoint for documents, wiki, and action items.
Some challenges
It's hard enough to arrange a weekly meeting, daily standups are infeasable
We're our own customers for the most part (we're part of a competition, but we can't work closely with the organizers)
Not just programmers, also mechanical/electrical team members
Sharepoint's action items don't have the best interface. Are there any extensions available? Would it make sense to switch to something else (like Trac) at the expense of a unified interface for everything non-svn?
Procrastination. As students, the most natural thing to do is wait to the last minute
We have our own space, but often, it's easier to do work elsewhere, and there's no way to predict if anyone else will be there except by making explicit arrangements
Other classes (still have to pass them, so total commitment to the team is limited)
Perhaps our team could benefit from more than just agile techniques, so all suggestions are welcome.
EDIT Thanks for all the great answers. I'm going to start asking my teammates how they feel about some of these ideas, and see what they buy into. Should I link them to this question? You can edit your answer or just leave a comment to answer this secondary question.
I wouldn't try to force a full, corporate environment style Agile programming workflow onto your team, but I do think that some level of Agile methodology could be valuable. I actually think that some of your "challenges" would be mitigated somewhat by some of the Agile ideas, but would require some level of commitment from every one on the team.
For example - the daily standups/weekly meetings issue.
This doesn't have to be a large thing (and, especially in a student project case, I'd say making it smaller is better). Having a Trac site (which I'd recommend over sharepoint if you're using SVN already) with a single place (like a wiki page) to just track the standup info in one sentence can still be valuable, without taking more than 1-2 minutes per day / person.
If somebody misses a day or two here and there, it's not a big deal, but if the team agrees to doing this, it can actually help the procrastination issue (forcing people to just say "I did nothing. I'm doing nothing" has a benefit - it keeps people at least thinking about your project, which tends to reduce the amount of procrastination), as well as having people work in different locations but still stay in communication.
This is also easy enough for non-programmers to do, and can help keep the mechanical and electrical teams working together, and everybody moving forward.
That being said, I'd make sure to keep it short and sweet - Try to keep the burden to a minimum, but I still think there's value in some of the Agile programming ideas, even in a student setting.
If you ask me you're adding too much overhead to your student project. Methodologies are generally only used in corporate environments because of the need to monitor and control human resources (control isn't the right word - but I needed one stronger than co-ordinate). In a group of students, there's absolutely no need to bother with anything like that. Adhering to a methodology will only slow you down.
You have identified your challenges. Make your peers aware of them and talk about how best to deal with them. Use methodologies as a source of ideas, but don't bend to one in your situation.
You can do a weekly or bi-weekly meeting that simulate a daily. Start your meeting with the three questions:
What did you accomplish since thelast time we met?
What do you plan to do until next time?
Is there anything blocking your progress?
Note that these can also be answered by your non-programmer teammate. In the company I work for, we have multidisciplinary team using scrum (programmer and artists) and it's working well.
If you don't want to do your meeting standing up, at least don't go for comfortable sofas. This should make your meeting shorter by making people more attentive.
You should use the method to your advantage and minimize procrastination by making interim milestones. Build your task list (excel, any other spreadsheet software is fine). Split them in milestone. When comes the time to review, sit with your team and look at your product like a client do, maybe involve your teacher.
Poker planning is fun, and a nice way to clarify your what you have to do, and how you plan on doing it. Breaking down objectives into tasks will involve people from all disciplines. But only people that can do the task should evaluate it.
IMO, SharePoint and agile don't really mix well. Pick something that's more "throw-it-up-there". I'd go with something like Trac, which has great Subversion integration.
It sounds like communication and procrastination is going to be your biggest challenge. If you don't give yourself enough time to do the work and do good testing, you're not going to have a good result. This is only logical, and doesn't really have anything to do with whether you're agile or not.
In your situation, not all of the Principles behind the Agile Manifesto will be easy to apply You might be able to apply some ideas that come from the principles, specifically:
short iterations at the end of which you always have a "working" project, even if some desired features have not been implemented yet.
maximize the amount of work not done - rather than designing a grand framework that you hope will cover all the needs of the project, start small and do just what is needed as you go.
If you have milestones during your project, consider having a meeting (called a retrospective) after each milestone just to look back and see how your process worked / didn't work and how you might improve it.
On the software parts, you could consider TDD and pair programming
I would say go with SCRUM. Skip the daily meetings and instead make a private forum and require each member to check it at least once a day. Try to make your sprint retrospective and planning meetings an "in-person" event over drinks or coffee.
The whole who is doing (and has done) aspect of SCRUM is amazing once everyone gets used to doing it. The 'sprint release' concept also helps team members from 'going dark' for too long and keeps the project based in reality ("What can we do in two weeks" vs. "I have this idea I am going to start and who knows when I can finish it").
Also, if your team has more then 8 people, skip SCRUM =)
Lastly, if you have the talent and someone on your team has the means (and desire), consider TFS workgroup (I think it comes free with academic MSDNs). If you don't have someone on your team who REALLY wants to take on that burden, skip it tho.
When I was in college, I took several courses that encouraged the adoption and use of Agile practices. They were mostly a mess and although I learned a lot of from them they generally weren't the things the professor was expecting us to learn. I do agile development professionally now and love it, but here are the things I wish that I had known when I was doing agile in school:
Getting things squared with your schedule is really, really hard, which makes daily standups more important, not less. If you can't sit in the same room (very hard) then use Twitter or Yammer or just email.
A lot of Agile's benefit is simply in getting you into a rhythm. That doesn't just mean weekly meetings; it means set goals, commitment to points, and weekly deliverables. This is tough to pull off in an academic context but should go a way towards helping you with your procrastination problem.
It's tough to get used to pairing; everyone has their own computer and style of development. Try to hook a second keyboard/monitor/mouse up to your existing laptops if possible, or use screen sharing software, and standardize on an IDE. Pairing also really, really helps with procrastination but trying to do it without good tools is an awful lot of trouble.
Don't skimp on unit testing, even if you think of it as a silly, academic, one-off project. I've done projects before that I figured were too small to bother with testing and it's never failed to come back and bite me on the ass.
Sharepoint might be a bit heavyweight. Believe it or not, we still do an awful lot of things on whiteboards or with index cards. You may be your own customer but that doesn't mean you can't have stories (discrete, estimable features, basically) and goals. It's helpful to be able to visualize it: these features are planned, these are in development, these are ready for testing. If you'd like software recommendations I can give you those but I do recommend simple paper for a lot of the planning process.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
If you had to make a case to a business about adopting or moving to an agile development methodology (like SCRUM or XP etc) what case would you make (how do you sell the concept)?
e.g.
How would you describe the concepts and benefits to a non-technical person?
If you have successfully done so, what was the winning argument/case/rationale?
Edit: The reason I ask is that a friend of mine (he is the solution architect at a firm) is currently trying to decide how to approach his management about exactly this topic, and I've given him what I can in terms of suggestions. Curious especially to hear from those who have successfully made a case to move to an agile-aligned methdology.
My Case: The organization thrashed around for a good 2 years and failed before finally jumping onto the agile bandwagon... there is no better alternative (as of now... personal opinion) to produce quality software at the rate at which the world changes. You cannot afford to make things the old way anymore. Some learn the hard way.
Elephant in the room: Just because an idea is good doesn't mean it will be accepted.
Logical Arguments:
Feedback loop is short. Customers can see working software at the end of each month/iteration, play with it... refine and tweak to taste. No more developers sucking dough for a year and coming back with an drunken elephant for the customer waiting for a horse.
You don't need to set everything in stone (the holy SRS) before development gets to work. You CAN change your mind to reflect change in business priorities/market conditions as time goes on.. (developers won't throw a tantrum).
Better communication: No more 'This isn't what I asked for!' when nothing can be done to salvage the ship. Dev talk to real customers in real time to clarify doubts and verify that they build the right thing. The onus is squarely on customer + development to ensure that the right product is built... by talking to each other.. all the time.
Human process: Agile recognizes the fact that software is made by people for other people. The practices facilitate interaction, learning and respect among the team. Better morale is also observed
Following practices like TDD, Automated tests, Pair Programming, etc. lead to better Quality products. Time traditionally spent in the 'bug-fixing-and-churning' phase at the end of the project is minimized.
Ease of maintenance. Regression testing is a SNAP! The systems built are amenable/easier to change/extensions.. if done right. The developers value simplicity vs over-engineering as second nature. Developers are not afraid to 'go in there and change it' vs 'I'm not touching that twisted thing.. last time's scars haven't healed yet.'
More realistic chance of meeting deadlines due to developer buy-in. Estimates are revised based on actual team velocity rather than gut-estimates of the person tasked with creating the chart/mpp/plan
Visible Progress - Big visible charts (burndowns, etc.) tell you exactly what's happening in the project without having to mine it out of secretive/reluctant/very busy people. Issues are In-your-face and can't be ignored/hidden for long. Development doesn't have to context switch to 'progress reporting' mode for a day a week to generate information for management... Easy to gather metrics that developers don't seem to mind.
Did I break the char limit?:)
Non-technical people are interested in projects done on time and within budget with good quality and which would satisfy their requirements at the time of the delivery. You should focus on how Agile helps to deliver those qualities.
It's sometimes quite difficult to sell Agile to a non-technical person for two reasons:
The concept of not trying to plan 100% ahead is not really intuitive
Quite a lot of people claim that they use Agile, fail miserably to deliver anything and give the great SDP a bad name
Talk about Agile process ability to handle changes.
It's usually easier if you work with the customer who already work with you. You could easily show them for example all of the change requests accumulated over the time and show how they affected the schedule and the costs of the project. You could then go into explaining how Agile process will help handling such cases.
Along the same line you could take the initial estimations done on a 'waterfall project' and compare them with real-life results.
I would also talk about the Agile approach to quality. Testing during iterations increase the quality considerably. Short iterations with immediate feedback are great help too, mention them.
Things that sell it well is:
Tangible product after each iteration that can be tested, played with, and released. (Good for a product owner who likes to see what his/her money buys)
It brings transparency to the development process, especially during daily stand-ups and so cuts down on functionality duplication and confusion
Having a demonstration after each sprint educates fellow employees about what direction the product is heading, what is available after the development work and gets people talking and thinking about what would make it even better
Development estimations can be made to a reasonable accuracy after a dozen sprints. At least after a few modifications to focus factors.
Improves developer buy-in as they get to own a particular functionality
Cost of product changes when using Agile tends to be much smaller than when using a waterfall methodology
Great for smallish development teams, but require buy-in from the development team.
It's almost impossible to introduce a new methodology without specifically referring to problems with the old methodology and how the new methodology is going to fix those problems.
In reality, you probably need to offer a bunch of choices, and then end with recommending your favourite. Come prepared with a good explanation of why it is your favourite, and with a really good knowledge of the weaknesses of your chosen methodology.
And make sure that you're not confusing the strength of your feeling for the strength of your argument, and that you're not trying to pass off personal value choices and cultural attachments as objective technical evaluations. Your colleagues aren't stupid - they will know if you're doing this, and they'll quickly flip the bozo bit on you.
If you want to get philosophical about this, communication doesn't actually depend on eloquence, rhetoric, or articulation, but on the emotional context in which the message is being heard. People can only hear you when they are moving towards you, not when your words are pursuing them.
In my experience, the one thing that instantly sells Scrum to non-technical management is the burndown chart. The idea that there is a paper chart - available for all to see and readily understand - that shows daily progress is an instant winner. It clearly shows very early on whether a project is on schedule.
Since the backlog, sprints, daily scrum etc are all required to make the burndown chart work, sell the idea of the burndown chart first, then explain there is a need for the rest of Scrum and finally point out that it is viable to perform a three week trial of the process with minimum impact to the schedule.
I think the number one selling point to the business is that they decide what you are going to work on, so they will be setting the priorities.
My boos, a non-technical person, usually prefer to listem about how a new methodology will improve productivity of the team. So, our aproach to introduce SCRUM, as a management methodology, focused on gains at progress visibility, better communication and sooner feedbacks.
All the other gains, as a fact of matters, seens intangible for people like my boss.
From what I have read and heard the term Agile seems to get a bad rap and scares people. From a business perspective I think what it boils down to is how can I provide business value in a more responsive way. Agile is a method of supporting the concept of delivering business value quickly.
Instead of discussing it in technical terms I would suggest your friend discuss it in business terms and state that he has some ideas that could help deliver business value to his end customers more quickly.
I would not reccomend he discuss XP or agile as the methods but instead introduce short, deliverable focused meetings (ie SCRUM) and then attempt to grow it from there. I feel if you tell the business that you can get them what they want faster and in a more predictible fashion and you deliver on that statement you will get buy-in to the practices that get you there.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The project is poorly defined: we are to write educational software for CS 111 Computer Programming I students focusing on functions. We have 6 student developers with various backgrounds working in Flex. The project has a duration of about 7 weeks. We have very limited face time (30 min per week) and very limited work time (<8 hours per developer per week). We have limited access to the customers (professor of our course, professor of CS 111, students in CS 111).
Our toolset includes Flex Builder, Subversion, and TRAC.
What methodology is best for this project and why? Alternately, what features should be gathered from various methodologies to better suit this situation?
What makes you think any methodology would be successful under these circumstances -- little communication, more requirements than time, and lack of access to customers?
That being said, I would focus on incremental delivery (each iteration should have some few working features), unit testing (all tests pass before check in), tagging of incremental releases (the ability to go back to a working release), and pairing of strong team members with weaker team members to boost the overall productivity of the team. Consider devoting one strong member of the team to integration testing.
Incremental delivery is most important. Showing a working demo of less than what was asked for is always better than showing a non-working prototype.
You could use Agile methodology here but obviously you'll have to adopt it to suit your needs.
For example if you don't have enough access to the real customers that someone with the best understanding of your goals will have to act as a customer proxy. I would also suggest trying to get more access to the customers - almost everyone try to appear more busy then they are and there is usually a way to resolve that obstacle.
Make sure that the limited work time your team have they have at the same time. There could be no Agile approach when you could not work together.
You could definitely use story-based estimations, iterative development process etc.
What is really important is too give every team member a clear and unambiguous understanding of how the Agile process works and what is each person's role in the project. It's very easy to say that you will use SCRUM but unfortunately without real understanding and experience that will not really mean much.
Some advice:
Educate your team members
Get a list of what you would like to deliver if you would not be limited by the time/resources.
Find out what is realistic to deliver given your constraints. That will probably be not much. Don't try to be overly optimistic. Focus on what you could really achieve.
Make sure that your real customers are on board for that.
Use short iterations (1 week or less). Make sure you could deliver fully tested product by the end of each iteration.
Show your work early.
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
As developers and as professional engineers have you been exposed to the tenants of Extreme Programming as defined in the "version 1" by Kent Beck.
Which of those 12 core principles do you feel you have been either allowed to practice or at least be a part of in your current job or others?
* Pair programming[5]
* Planning game
* Test driven development
* Whole team (being empowered to deliver)
* Continuous integration
* Refactoring or design improvement
* Small releases
* Coding standards
* Collective code ownership
* Simple design
* System metaphor
* Sustainable pace
From an engineers point of view I feel that the main engineering principles of XP arevastly superior to anything else I have been involved in. What is your opinion?
We are following these practices you've mentioned:
Planning game
Test driven development
Whole team (being empowered to
deliver)
Continuous integration
Refactoring or design improvement
Small releases
Coding standards
Collective code ownership
Simple design
And I must say that after one year I can't imagine working differently.
As for Pair programming I must say that it makes sense in certain areas, where there is a very high difficult area or where an initial good design is essential (e.g. designing interfaces). However I don't consider this as very effective. In my opinion it is better to perform code and design reviews of smaller parts, where Pair programming would have made sense.
As for the 'Whole team' practice I must admit that it has suffered as our team grew. It simply made the planning sessions too long, when everybody can give his personal inputs. Currently a core team is preparing the planning game by doing some initial, rough planning.
I consider myself lucky, all except "Pair programming" we can do it, but only to solve big issues not on a day-to-day basis. "Collective code ownership" is hard to achieve as well, not doing pair programming we tend to keep the logical next user stories from iteration to iteration.
Whole team (being empowered to deliver)
Small releases
Coding standards
Collective code ownership
But then, I do work in a mission-critical development team that's quite conservative. I don't necessarily thing XP is a good way to develop, you must find a way that's right for you and ignore the dogma.
We've done everything except small releases and it's been great. I can't imagine working any other way. From my experience, the tenets I value most are:
Continuous integration (with a solid test suite).
Collective code ownership.
TDD
Team empowerment and decision making.
Coding standards.
Refactoring.
Sustainable pace.
The rest are very nice to have too, but I've found that I can live w/o pairing so long as we have TDD, collective ownership, and refactoring.
Pair programming[5]
It is hard to convince management of this aspect. But I have found this is doable when an engineer gets stuck or we have an engineer who is new to a technology or effort.
Planning game
Yes.
Test driven development
Easy sell to management. However the hard part of some management is adding in more time. A lot of managers believe that Extreme and Agile programming will save them time. They don't save time to deliver you something. In fact, the testing constant requirements gathering adds effort. What it does do, is it gets the customer what they want faster.
Whole team (being empowered to deliver)
Definitely, this is an amazing facet to Xtreme.
Continuous integration
At the end of each iteration (sprint) full integration occurs. Daily full integration does not occur.
Refactoring or design improvement
Your first effort is rarely the best. So yes, I find Xtreme constantly yields better and better solutions.
Small releases
I find that given the infrastructure and resources that can lengthen the suggested length of an iteration of 1 or 2 weeks. A lot of this depends on where you are deploying to. If you system is being deployed to a production environment, formal systems and stress testing can add a lot of overhead. So in this environment, we go with iterations lasting a month or even 2 months. If the system is being deployed to a development area and has not been deployed to production, even something as tight as an iteration lasting 1 day can be doable.
Coding standards
Pair programming for new team members can promote this. Code reviews also can help here. A lot of this depends on how long you have been working with each other.
Collective code ownership
I haven't found that Xtreme really helps here. Everyone naturally falls into certain areas of the code base. So people get ownership of things they spend a lot of time with. This can actually be a good driver as good software engineers will take pride in what ever they write this way.
Simple design
Short iteration cycles do in fact promote a simple design. It needs to be maintainable for the short releases.
System metaphor
Not sure what is meant here?
Sustainable pace
Velocity of a team is a task that can only be acutely estimated with proper metrics. Metrics need to be kept on task estimates and task completions durations.