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
Would you recommend extreme programming practices implemented in organizations where team composition changes often?
If in an extreme programming scenario, the team becomes volatile midway, what would you recommend?
Thanks.
I would suggest that the issue of team volatility is addressed first. No process is going to work very well if you've got a revolving door in your office in the first place and I'd say that using a process that relies more heavily on an individual's performance and contribution than one intended to be used with "replaceable cogs in a machine" is going to make matters worse if that's possible.
Pair programming might work in a situation like this provided you can keep some people around for long enough so that they can impart their knowledge on new members on the team. However part of the problem with that is that you can't really practise the "pair of equals" part of pair programming and you'll end up in an implied senior/junior situation simply because one half of the pair doesn't know the code well enough.
Most development processes rely on a comparatively stable team that does know the codebase well. If you don't have that, you need to design a process around the fact that you will be dealing with developers that are trying to grasp the codebase at the same time as they're trying to be productive.
Programmer Pairing becomes a must. Engineer practices (XP) along with management practices (SCRUM) enables to deliver at a sustainable pace. One of the first things you should emphasize for a working team is to keep it together. If that is not possible, programming pairing carries even more importance!
For waterfall, a project is started, people are gathered, they then have to go through Form, Storm, Norm then Perform. Once the team learns how to work together, the project ends and the working team is disbanded. Then the process is repeated again. Do you see the problem? Who has so much money that they can continue to pay the cost for teams to Form, Storm, Norm then Perform again and again?
That being said, every team will see team people come and go. With programmer pairing, you can bring new folks to the team and they will become effective almost immediately. By pairing they will learn the business domain, application code and engineering practice very quickly.
We took a team of 4 pair and added 3 new pairs to the team. We paired all the new developers with experience team members. We gave ourselves 30 days to bring the new members up to speed. The team hit all deliverables. Could you image adding 6 developer to a team of 8 developers on a waterfall team. The team would nearly grind to a halt assimilating the new team members.
Bottom line, keep a function team together. If that is not possible, make effective use of pairing to bring new folks on board quickly.
What process is going to work when the team composition is volatile? At least with XP, using pair programming, you have some hope that more than one team member has some familiarity with all parts of the code. FWIW, I don't practice XP, I just don't see how the issue is exacerbated by using XP.
Pair Programming should help with getting new team members up to speed, as well as osmotic communication in a team room. Extensive suites of both developer and customer tests should make sure that new team members don't break existing functionality. High code quality should help them find their way around faster.
Having said that, volatile teams are really a strong antipattern. Why do you have them in the first place?
High test coverage and a continuous integration can help ensure that new team members do not break what was previously implemented. Pair programming is the fastest way that I've found to help someone get familiar with a project. Planning meetings, short iterations, and tracking velocity over those iterations could also help new developers easily bite small pieces that are more easily managed.
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 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
While studying a software methodologies, I often see disclaimers along the lines of "This methodology requires a mature development team."
Which development methodologies are specifically geared towards immature development teams? I'd assume this is where most teams should start.
Let's define an immature team as a team whose members haven't worked together before, are working in an unknown environment (i.e. new company), and who haven't defined their processes and controls yet.
My $0.02
It is not really the case that any methodologies are specifically geared towards immature development teams per se. However if there is a characteristic of a methodology that would be beneficial for inexperienced developers it would be "well defined process".
The reason for the disclaimer ("requires a mature development team"), and this is nearly always applied to Agile methodologies, is that they require discipline and experience (which can only be gained from working on projects and learning from mistakes) to choose the right steps and make the right choices. Mature (read: experienced) developers know when it is safe (and not safe) to cut corners that inexperienced developers might do recklessly at every turn anyway. Also experienced developers have better intuitions and make better first choices, and know how to refactor designs and code properly when required.
To recast a famous quote from Bjarne Stroustrup into matching methodologies to (in)experienced teams, you might get: "Unleash an experienced team on a methodology that allows great flexibility and they might well shot themselves in the foot, unleash an inexperienced team on the same methodology and they'll probably blow their leg off".
(Apologies to Bjarne, and anyone offended by the thought of leg injuries:)
It helps to have someone who is familiar with methodologies who can pick and choose what to add when. Trying to through a full blown methodology at an inexperienced team will likely overwhelm the team. Assigning someone senior to own the process would be a good idea.
I would start with version control and continuos build processes first. These will help identify if other changes break code. Automated testing tied to the build process would be a close second. Choosing what to build and when is also critical.
Throughout all of this communication about what is working and what is not should be occuring. Change what doesn't work, and continue adding.
The tough part is to produce stuff while this is happening.
If you have code to maintain, you may want to start with a small team working on new code to develop the methodology, and spread it to the team.
The methodology should drive getting the right information to the right person when it is needed. If the methodology is getting in the way of generating working code address the problem.
Reveiw the waterfall methodologies for things that need to be considered. Review the agile methodologies for how to consider things at the right time.
I can only advise you to set the environment, start working, and your team will adjust to the chosen methodologies. Create small release cycles, and adjust the chosen methodology at the beginning of every new release cycle.
Introducing code/design reviews can be a very valuable first step. It (if introduced correctly) can develop team bonding; can lead to "egoless" programming; lead to sharing of knowledge and learning; and picking up errors early in the process, when enthusiasm can lead to major pitfalls. Like #BillThor I think version control is valuable, but would suggest that teams generally need to experience the need for it before they will whole heartedly adopt it, and that this occurs only after they have had a versioning caused problem. The element that is useful for my answer, #Bill's and #Peter's is a capacity to have mentoring available. This (ideally) would be the role of a manager with development experience, or a senior developer.
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 have been interested in agile methods of late and have found a lot of prescriptions and minute descriptions of a lot of practices.
Still, I remember my best projects as run-to-completion spikes followed by some debugging and minimal testing before going live.
I have been asking myself, did Flickr use agile methods? Does Facebook practice TDD? Was Gmail made in 25 minute spans followed by 5 minutes of daydream?
In other words, before I listen further to all the preaching and jump into the manuals, what evidence do I get that this is the way to be successful in a successful project in a successful company?
Of course, I am asking this because I want to read the answers, not because I want to dismiss an argument.
A related question is, how many non-Agile (Waterfall, "Big Design Up Front", etc) projects are successful? In my experience, not many. In fact, I just rolled off a two-phase project in which the first phase was traditional Waterfall and failed pretty significantly, but the second phase was iterative in nature and yielded substantially better results (on time, far fewer defects, end result was closer to client's actual needs than the original spec).
I've been doing Agile development for a few years now and, overall, have found it to be superior to the alternative. A few things I've noticed:
Agile != "no process". Agile is about having only as much process as you need and continually refining that process.
Agile requires discipline. You not only have to have a process, you have to follow it.
Agile won't turn a failing project into a success. It can help you identify that the project is failing sooner rather than later, and help you figure out why it's failing. It's about shortening the feedback loop so that you have a chance to get back on course before it's too late.
Microsoft Research recently posted an article in which they empirically evaluate some Agile methods. It's well worth a read and might provide some of the information you're looking for.
Here's a successful project of mine: http://www.sky.com
Went live after a few months.
Delivered new functionality to the CMS and servers behind the site weekly - with deployments typically every week or so.
All done with all the extreme programming disciplines.
Weekly demos to the customer to go with the weekly iterations.
Here's another agile project (also done strictly with XP), also a big success: http://showbiz.sky.com/
I've also worked on two other successful XP projects:
Banking A system for cleaning up and distributing fixed income data across investment bank sites in NY, London, Paris and Tokyo. I believe the whole project only had one production incident over the course of a few years.
Mobile Data A system for configuring mobile phones and PDAs for mobile networks and handset manufacturers. We built the core product incrementally over a number of years and co-ordinated the work over three sites across the world. All done using extreme programming. Customers were some of the largest companies in the mobile business. Our apps provided global support for some of these clients.
I really wouldn't go back to the old way of doing things - and neither would the customers that sponsored the projects I've mentioned above.
In most of the big companies (IBM for instance), the methodology is not always the same, Agile or Rational or Waterfall. That depends in a lot of the history of the projects and the experience of the current People and Project Managers.
If you plan to develop on something is always good to check on all the sides before deciding what suits best for your plan.
So the short answer is: It depends.
My product (the Sophos Email Appliance) is developed using agile methods. Industrial Extreme Programming, as espoused by Joshua Kerievsky, was used for the first several years of development. Recently I have started to move the team more towards Kanban, visualizing work flow and using pull-based scheduling instead of time-boxed iterations.
In other words, before I listen further to all the preaching and jump into the manuals, what evidence do I get that this is the way to be successful in a successful project in a successful company?
There is empirical evidence that most IT projects are not successful (where success means on time, on budget and fully functional here). Given this evidence, it seems reasonable to wonder if a deterministic approach (the waterfall) is well suited for software projects.
"The definition of insanity is doing the same thing over and over and expecting different results." --Albert EinsteinRita Mae Brown1
If a deterministic process produces failures over and over, we are likely not applying the right process for software development projects and Agile methods are an alternative. The theory behind these methods is that most software projects are not deterministic, they are creative (like in art) and complex (as defined by Ralph Stacey) projects and we can't predict everything. So, instead of trying to predict everything and then fighting against change, we should use an adaptive process. And this is what Agile methods are about.
Now, using an Agile method will never guarantee systematic success (and someone claiming the inverse is a liar) but they'll give you better control over the risks. And, if your project has to fail, it will at least fail fast.
Update: 1 Actually, this quotation seems to be misattributed to Albert Einstein. The earliest known occurrence, and probable origin, cites to Rita Mae Brown.
I believe Doublefine just produced Brutal Legend using Scrum.
From what I understand StackOverflow is a successful website built with agile practices and TDD.
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
Let's say that a developer is interested in learning Scrum, but nobody else on the team is interested. I realize that Scrum is made for teams, and the process would have to be modified to fit a single person.
Is there any benefit to be gained by the developer trying Scrum, even if the team doesn't? If so, how would the process be modified to suit the situation?
I think there's benefit to be gained by any method that helps you develop goals, tasks, keep on top of work and deliver something often.
Your individual work-products would gain the same advantages that teams gain with scrum:
You'd get something done every {Sprint Iteration Period Here}, something you can hand off and say "This is now ready".
Your estimation technique will start to improve with reflection and retrospectives
You'll start to plan your day and make commitments to yourself about getting things done, so again your estimation of your capacity will increase
Retrospectives will formalize improvement of your personal work process. You'll start actively improving, removing and adapting to suit you and your individual needs.
You wouldn't be able to rely on other team members to help out, which is a bit annoying, and you wouldn't have a product owner, Scrum master or a backlog to pick tasks from. You may not even be in a position to make decisions on what to work on next. But I think the formal discipline and reflection is helpful for all craft practitioners, at all levels, alone or in groups.
And who knows, you might even inspire your team to Scrum it up once they see what great results you're getting.
I would suggest that you use Extreme Programming instead, as that works better for one programming than a decidely team-based process.
Then you can get the benefits of being more agile, but if your team is not agile then you will have some issues due to the use of a different paradigm.
For me, the biggest key was getting buy-in from my supervisor. It can be tough to try and have some sort of Sprint only to have it interupted multiple times (Supposedly XP teams handle this better, but I don't think any developer does.). Also, don't forget to include either power users (they could be testers) or members of other departments that could be used as Product Owners. I like to sit with other users and do a type of paired programming (OK they don't code) where I can ask questions while coding and do quick demos to get feedback. This helps when I'm struggling to create specs because those requesting the app are having a hard time telling me what they want.
Even if it's just you in the daily stand-up, it can be scrum.
If you compare yesterday's planned with actual and define today's plans -- without talking to other people -- that's still a kind of daily stand-up.
I'd say that what you're doing probably is scrum if you're following the daily-sprint-release cycles; even if there aren't a any other people to talk to each morning.
G'day,
For the best thing to come out of learning Scrum is the concept of involving the customer early and often. That way there are no nasty "that's actually not what we wanted" moments when you deliver to the customer after six months hard work.
HTH
cheers,
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.