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 trying to get our software department to adopt some kind development process methodolgy. We only have 9 developers, and about as many projects. Currently, we can only be described as chaotic. Or perhaps 'crisis driven development' as I've seen another SO user call it.
Using Kanban seems like a it could be a good fit for us. So I've discussed it with everyone else, everyone thought it sounded good. But when we discussed how the board(s) should be arranged, everyone wanted to do one board per person.
Now, I've never tried Kanban, or any methodology really, but it feels like having each person managed on their own board would negate the benefits a Kanban process is supposed to provide. This notion makes me sad, and want to say 'ho-hum let's scrap this whole idea.'
Do you think implementing a Kanban board per developer can be worthwhile?
If you must have a multitude of boards, wouldn't it be better to have a board per project rather than a board per developer ? Maybe in time some natural groupings of projects (and therefore consolidation of boards) will emerge, maybe not.
One purpose of the boards is to serve as "information radiators". A large number of project boards progressing at a snail's pace broadcasts the message "we are seriously overloaded" and/or "someone needs to set some priorities". A large number of per-developer boards just radiates the message "we don't do teamwork around here".
Kanban is actually as system for restricting flow through a system, which is why we have WIP (Work In Progress) limits on kanban boards, and as a person can do only one job at once I don't think this could work.
Having one board per developer really doesn't give any advantages (And I'd argue it's not really kanban). One board per project is a better idea.
Then if another developer joins in for some tasks you can still see the overall progress of the project.
I think it might be worthwhile to have another discussion with your group. Before adopting any kind of new technique/practice/methodology, one should be very eyes-open about why you want to adopt it, and what problem you're trying to solve. It almost sounds to me that you've stumbled upon Kanban Boards and want to adopt it without really knowing what problems you're tryying to solve.
My advice would be to try do some more thinking or analysis on the problems you see in your environment, do some root-cause analysis if you can (something like the 5-whys), and then try find some practice that will help you solve those problems.
The very fact that people in your group suggested using a board-per-developer implies to me that a. they don't understand the kind of problems they have, and that you're trying to solve, and b. they don't understand what Kanban boards are trying to achieve. I.e., your problems are such that using Kanban boards will not solve them.
It's not wrong to have a board per developer. The board is there to visualize the work. If the developers work on different projects, then it would be easier to visualize project-specific work with separate boards (which is usually the case). If your developers work on separate projects, then they work on separate projects. Technically, they're not really a single team, but more of a "practice". From that perspective, it might be a more natural approach to have them working separate boards.
When I work on personal projects on my own I still use a Heijunka Box - what software developers in the west often (mistakenly) call a "Kanban Board" - and I do this to visualize work, work scheduling, and to help limit the number of things I'm working on at once.
I've implemented Kanban for my team which does Operations Automation (more or less half Ops work and half Dev work). Here's what we found worked best for our team. We have a common column for INBOX/Backlog.. Then a 'in development' column broken down into 5 sections, one per developer, with a per-developer WIP Limit. Then another common column for 'to integrate', and finally a common column for 'release to production'.
The advantage of Kanban is that the WIP limit ensures developers can focus on what they are doing - in our case each developer is fairly autonomous in working on their project, but we have the common columns for INBOX where a developer can pull any new task, and for 'integration' / 'production' where the team-lead is involved in shepherding the change through the remaining steps.
So my recommendation is to have some common columns (perhaps your backlog and your release) and have some columns that are per developer (like 'in development'). That way each developer can manage what they are working on, and at the same time the board can help visualize the state of all work that is flowing through the pipeline.
The two most important reasons to apply Kanban to a process is to visualize that process and limit work in progress (WIP).
If you have one board per developer it's more of a personal kanban mechanism, and you get to visualize and limit WIP for one person at a time, but no overview at team level.
If you have one board per project or team it depends if there's shared resources, i.e., people working on more than one project or team. If so, you loose some overview and some of the benefits from limiting WIP if you have people working on stuff shown on more than one board. F.ex. bottlenecks are harder to see.
My feeling is that it might be better to use one Kanban board, with all the developer tasks on it, rather then one board per developer. Reason I think this is because the idea is that Kanban is a visual tool for all team members, and if each dev has their own board, then I think it misses the idea a bit.
Subnote
If you're using Microsoft TFS, then you could use use Telerik Work Item Manager. I've used this myself and it's great. Each developer runs a copy of the tool on their PC, and they can view their work items on a visual task board (with colour post-it's). This board can grouped and filtered by various ways, so a developer can see all their own tasks, but then they can change the filter to view all the tasks on the project.
(If you're not using TFS, apologies for the uninteresting subnote :)
Indeed, create at least 2 or 3 teams, affect only one project to each of them and so one board by project. Then an another board to manage projects status.
To resume: One by project with every tasks, one to follow project status it will help the developers and also you to communicate with the managers.
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
I'm very positive towards agile development, and have worked on agile projects on and off for about 13 years. But I have a concern that I've never really been able to address. It doesn't always seem to manifest, but it has bitten me a few times.
Agile seems to be in some sense a 'greedy algorithm'. Start with the highest value story, optimise the system to precisely fulfil that story, and repeat.
Actual greedy algorithms are prone to suffering from converging to locally optimal solutions, while missing a globally optimal solution.
Has this been people's experience?
Is it actually a problem?
If so, what techniques do you use to avoid such local optima and yet remain agile?
Actual greedy algorithms are prone to suffering from converging to locally optimal solutions, while missing a globally optimal solution.
This holds true if EPIC technical User Story and guideline is not established, along with the normal business EPIC user story.
Has this been people's experience?
At times yes, it has been my experience. One instance was when the user stories we worked on were broken down too much, and the solution was to broaden them to get a more global outlook at our designs. And at times it was different enterprise scrum teams in the same projectt, conflicting with different technical framework uses and approaches.
Is it actually a problem?
It is only a problem, if you ignore the technical EPIC user story or guideline.
If so, what techniques do you use to avoid such local optima and yet remain agile?
Here is one Agile approach to solving this:
During Agile Release planning, instead of just coming up with a Business EPIC User Story, also come up with a Technical EPIC User Story. The Technical EPIC User story would have the product vision from a technical stand point, in terms of technical architecture, application framework, quality standards, and global design considerations etc. These could be broken down into smaller technical user stories, and have a Scrum Team which works on getting those user stories working. An example of a user story could be: "As a Technical Project Manager, I want the whole enterprise project using A, B, C framework, and coding as per X,Y,Z coding standards, so that there is uniformity in project development work.
If you don't want to form a scrum team separately for this, then just keep them as reminder cards next to backlogs for development teams to use as guidelines.
As a testing guideline, we used to have successful integration testing as a done criteria for each backlog. A global test was conducted in an integration environment, on all working software deployed from all enterprise teams, to deem it shippable. So right from inception to end of the backlog, the theme is set for global working software and not just local working software.
Finally, Agile development involves keeping a constant eye on quality, and one of the quality issues could be bad design or a too localized design. As and when this is discovered, it should be redesigned within that backlog itself, and followed going forward for other Backlogs.
I've been on a project which has had this problem, and has not dealt with it effectively.
The local quality of the code - over the scale of a package, say - was not bad. But there were problems at larger scales; things like duplication of logic (but not code) between packages, use of batch recomputation jobs where we should be using event-driven approaches, splitting the system into separate services at the wrong place, etc.
None of these problems could be fixed by refactoring a single class or package. As a result, they never happened in the normal course of events. We did refactorings at smaller scale - when adding a feature, we'd refactor in that area before starting, and again after we finished (as well as making some effort to write good code as we were going). But that never led to refactoring larger, architectural concerns.
We were all conscious of the problems, we just didn't have anything in our process that let us fix them.
One notable victory we did have was where there was duplication between two distantly related module. Essentially, there was code to render a web page showing the results of some set of calculations, and also a background job to generate reports doing similar calculations. The calculation code was shared, but the code to set up the calculations was not; one was driven by a user's view preferences, whereas the other was driven by a configured reporting job. We had a feature to implement that would have involved adding a new aspect to the calculations, which would have meant adding more items to both kinds of configuration, and then adding business logic to both sets of calculation setup code. We managed to get the product manager (our customer proxy) to agree to budget enough time for the work that we could refactor to unite the ideas of user view preferences and configured reporting job, so throwing away one of the sides of the duplication, then implement the feature. This took longer than just implementing it twice, but the product manager was wise enough to realise that this would let us implement future features spanning both pages and reports more quickly.
The mechanism in the process by which we did this was writing stories for the job of refactoring. Essentially, something like "As a product manager, i want pages and reports to use common calculation setup code, so that i can get features added more quickly". This is absolutely not a proper kind of story, but it fitted in the system, and it did the job.
I think that if the running of this project had been a bit healthier, then there would have been a steady stream of stories like this. We would acknowledge that we had a lot of architectural debt, and that work to pay it off had value, and allocate a fixed fraction of our time to it, perhaps about 20% (which would really mean one pair at a time). We could then have generated features/epics, stories, and tasks just as we did for customer-oriented work. These would originate from the team themself, rather than the product managers.
Sadly, there wasn't quite enough communication and trust between the development and product management sides that this was feasible; we could say to product that we had a problem, it was important, and that it would take so long to fix, and they couldn't know if that was true or not. As such, they were generally unwilling to schedule time to do it. The sad thing was that everyone was in agreement that there were problems and it would be good to fix them, we just had an impasse over actually doing it.
in my experirence, if you´re working a project context with fixed time/requirements then yes, most of the times Agile leads to local optima.
But my point is that in a complex endeavour, the requirements, the team itself and even the goals change. Agile is also about embracing changes.
Then, paradoxically, this greedy strategy arrises as a reasonable option for global optimization when dealing with moving targets.
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'm trying to figure out how to solve some challenges that my team is facing while attempting to apply agile. The one that is causing the biggest headache at the moment is due to the dual role nature of projects that come into the business.
Basically, we have a number of software that we produce and deploy for various markets. This software is planned and scoped in quarterly release cycles. At the same time we have large contracts come through that take anywhere from 1-3 months to complete. The problem comes from the fact that management wants to work on the incoming contracts first and foremost and all normally scheduled release work is brushed aside to get the next contract out the door.
We're trying to scope the releases to shorter than 3 months so that a contract would have to wait that long for work to begin.
Has anyone dealt with a scenario like this while trying to apply agile? What are some ideas/approaches to working on release scoped/planned work and keeping management happy that high priority contracts are being delivered in a timely manner?
The only way I can see is an internal market.
Assign a $ value to the next release of your 'real' product and then you can fairly apportion effort to that vs the incoming contract.
Of course the value of the 'real' product depends on management but at least it pushes the problem onto them in a rational way.
Instead of looking at your situation as multiple shorter projects that are interleaved into one longer project, you might instead think of it as a single larger project. The small projects then become interrupts or the equivalent of scope changes, which are things that all large projects need learn to manage anyway.
As with interrupts and scope changes, you will need to address schedule impacts, the effect of "context switching" overhead on your staff, etc -- and possibly consider dropping features or cutting back in other ways in order to make your next scheduled delivery date.
If management wants the new work to be done first, while the mainline project is put on hold, then it seems to me that's what you should give them. Why drag your feet for 30 or 45 days before starting the new project? From the perspective of a single larger project, that's certainly not very agile. You could instead get a faster start, and then communicate the resulting impact.
Over the long term, you may find certain staff members are slowed down more by periodic course changes than others. In those cases, you might consider making semi-permanent assignments, so they can continue what they were working on, even in the event of interrupts. Similar arrangements are typical in larger, interrupt-driven shops.
Even in an agile workplace there is some kind of "resource planning" at management level. As long as there is some predictability on when the contracts come in, the allocation of people to teams and between teams can be decided before the start of each iteration.
If an unexpected event occurs and it is necessary to terminate a sprint, or re-plan it mid-iteration then that's what you have to do.
Agile methodologies are supposed to help you to "embrace change" and make sure that the highest value requirements are delivered first. They don't change the fact that there is always more work to do than people to do it, but they do provide a framework for managing the chaos that this will cause if people aren't realistic about priorities, actual staffing levels and work rates (or "velocity").
Agile doesn't mean that there won't be difficult conversations, but if it's done well then the conversations should mostly happen in time to take some kind of corrective action.
I'm assuming that there is some kind of officially sanctioned agile process in place. I don't believe that agile methodologies (e.g. Scrum) can be made to work under the radar, because:
Agile methodologies are about self-managing teams. If your management doesn't accept the teams' right to self-manage then there is going to be a power struggle.
Agile methodologies are about having high quality communication both within a team and between the team and it's stakeholders. It doesn't work if the process is hidden from the stakeholders.
From the comments above, your process seems to be in pretty good shape. You have identified a genuine business problem and you are having a constructive dialog with your management team.
If you haven't got management buy-in, doing Agile is very difficult.
By the sounds of it, the management don't have a problem at the moment. They drop a contract on you, you do it, the quarterly release slips but they get the nice contract money.
Is your team large enough that you could conceivably split it into two teams: one focused on the internal releases, one focused on contract work or perhaps two teams that swap over responsibilities after each release so they each get to spend some time on green field and some time on BAU projects.
On a general Agile methodology note, you'd be better off with Kanban than Scrum because it sounds like if you tried to plan iterations, you'd end up with 90% of the work in the unexpected 'contract came in' column.
Who is driving the quarterly releases on your product: customer requests or what you would like to do? Like mgb said, what profit is the business making from them?
I think it's first important to define by what you mean to "apply agile." There are a lot of different parts of agile and I would try and start small with the pieces that you can do. For example, do you have a continuous build running? Have you developed a product backlog?
Working on multiple projects is difficult to begin with but without management buy-in (as Wysawyg mentioned), it will be difficult to become more agile. You need to show the benefits of agile development in terms of cost savings to management. Have you determined why you want to become agile? How will it help? Once you have shown why, then just start doing some of the pieces that you can and after you start seeing some improvements, talk to management about the bigger pieces.
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 8 years ago.
Improve this question
After learning about source control the first thing I did is do a project with svn. After learning about git I used it in a personal project. After learning about UML/Design Patterns/Design Principles/TDD I applied them to a personal project. How can I do the same to agile development? Is agile just for teams and big projects? How do I set up these iteration things?
I think Agile is definitely not just for team projects. Agile advocates a set of values that apply equally well to many types of projects, even personal ones. I was in exactly your situation a while ago, trying to apply agile development to a personal university project, and learned a lot in the process. Some useful things that the agile mindset can give you include:
Work on stuff that adds value to the final product. Make yourself a backlog of features and prioritize them as though you were the customer. Then discipline yourself to work on features based on their value to the product rather than what you want to do right now. This might save you from a lot of unnecessary, over-designed code that you won't use. If you have a deadline, it's even more important.
Have an evolutionary design: start with The Simplest Thing That Could Possibly Work and Refactor Mercilessly.
Postpone decisions until the Last Responsible Moment.
Timebox yourself into sprints or iterations (VERY important on university projects).
...
If you go over some of the agile methodologies again, I think you'll find plenty of values and practices that you could apply by yourself.
While writing this answer, at least 3 other answers came up and beat me to it. I agree with all of them. :)
Make list of tasks and features that you want in your application. Take those tasks and put them on a card wall.
You can't really have a meeting by yourself, but in the morning decide what you will do for the day and what you successfully did yesterday. Take those tasks, do them and then move to the next. Make sure at every point you are delivering continuously integrated, working software and you update your backlog. You might have "bug bash days" where you just fix bugs. That would be a one man scrum. :)
It's hard to truly apply agile coding to one-man projects because many of its benefits are aimed at small teams where you can quickly collaborate on focussed areas.
That said, you can adopt some of the techniques:
Release often
Focus on your users' needs
Feel free to deviate from major version plans - you can change direction whenever you feel the need
Spend less time in setting up major frameworks and get something working as soon as possible. Then go back and refactor to accomplish your original needs (if they still apply)
Other than pair developing, you can do the remainder of the practices if you are willing to play multiple roles. If you have someone who is willing to work with you, you can also do pair developing.
First you would build a product backlog. This would be a prioritized list of features or story cards you wish to develop. No card should be bigger than the work you can complete in a single iteration or sprint. If your sprints are a week or two, that will determine the size of the features or story cards on your prioritized product backlog. As the product owner, you can change the priority of the product backlog for each iteration. From the product backlog, you could build your iteration and release plans.
Since you are playing multiple roles, you will need to allow time for you to author the story card. The story card should sketch the GUI, describe the primary and secondary workflows and most importantly have acceptance criteria.
Once you sign off the written story card, you can begin development on the card. You would use TDD (test driven development) to write the test first, then the code. You would repeat until the card is done. The acceptance criteria would help you decide what unit tests to write.
Once the developed of the card is done, you would write the automated functional tests. You could use Quick Test Pro, FIT, Cucumber or some other favorite automated unit test tool. I would stay away from any play and record features as that can drive up rework in the future as you refactor.
Once the unit test is completed and the card passes, it can be added to all other automated functional test and can be run at least daily if not at every check in.
At the end of the iteration and prior to moving your working software to production, you can perform the User Acceptance Testing.
As the developer you should use continuous integration, automated builds kicked off with each of the frequent check in to your source code control system.
After the story card has been written and prior to developing the cards for the iteration, you can task them out (i.e,. provide estimates for each of the tasks required to develop the card). You can determine if any refactoring needed can be completed within your estimate or if you need to create a new story card that captures the technical debt you identified.
As you can see, you can take a single member agile team very far. Given that the agile management practices help collaboration and identify what is important, you can benefit from those practices also. Given that the engineering (XP) practices enable the code to remain healthy thus supports sustainable pace, you code will remain flexible, contain a strong unit and functional automated test harness and allow you to continue development at a sustainable pace indefinitely.
Is possible to use Scrum for one man projects.
Create backlog
Optimal time for one sprint is half day
At Friday create plan for next week and every half day update burndowns for each projects.
For example, don't be afraid to refactor your own code, even if it works, if the result is more flexible and robust.
A few thoughts on this:
Iterations are as long as you'd like them to be
IPMs are still possible where you pick what you want to do over that length of time
Demos at the end are still useful to see working functionality in a somewhat professional manner rather than your own little debugging area that may not be as clean or orderly
Retrospectives are still useful to see what is and isn't working for yourself at a point where you can see the forest for the trees in a sense
It is quite possible to be Agile in a personal one-man project, IMO.
All of the advice here is good, but there is one important aspects of Agile that usually goes unmentioned: monitoring.
Agile asks you to take a look at what you have done, what you are doing, where you are going, and make appropriate course corrections if needed.
I think Big Visible charts and Burndown/Burnup charts are so useful, I wrote a program, Task Analytics, to make these charts easily. It's perfect for small or one man projects.
Good luck.
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
For those of you who have implemented Scrum in your organizations, what were your biggest obstacles and if you did overcome them, how?
Background: In 2006 I contracted with a large company which had adopted Scrum cold turkey just months before I arrived. The company hoped Agile/Scrum would save their huge enterprise software product. Of the hundred or more programmers there, I worked closely with a team of about a dozen for a year, observing and participating in their Agile experiment.
Summary: I believe Agile helped more than it hurt. By the end of the year, the team could consistently estimate and produce features, whereas previously their productivity was rather erratic.
Implementation: Since this was a large organization and a large product, the project ran as a "scrum of scrums." There was one scrum master for about every 15-20 developers and these teams were often divided into smaller, closely working scrums of about 6-8 people for an iteration. Teams were largely independent, could adjust their own iteration frequency (1 month down to 1 week) and were given lots of flexibility to implement agile as they saw best. The company regularly brought in Agile coaches (such as Object Mentor) to help train the scrum masters, teams, and management.
Obstacles: Plenty. Some of them related to Agile, some not. In no particular order, here are some lessons learned:
The product backlog was revised way too often in the beginning. Eventually, the team and management took several days to go over all the features, estimate them, and prioritize them. It was a big hit, but it helped tremendously. Lesson learned: get your product backlog in order early and keep it maintained. Product owners must have a clear idea of what they want.
We lost time experimenting and dealing with fads and hype. When you start, you have no way of knowing if you're doing things correctly. There's temptation to constantly fiddle with the agile process taking the focus away from the product. Lesson learned: having an experienced Agile coach does help reduce this learning curve. There should always be someone pushing back on any experimentation. Limit the number of "spikes".
A good scrum master is invaluable. Certainly in the beginning, it's a full-time position.
It takes time. It took several months before the team started to be comfortable with the process.
Pick your battles. Some programmers will be understandably skeptical and others will outright dislike and flight the change. Allow for some flexibility. For example, enforce the use of a product backlog and iteration schedule, but don't require everyone use note cards. Be particularly sensitive to introducing tools and programming methodologies such as pair programming or test first development.
Finally, keep communication open and manage expectations.
Good luck!
While working as a Delphi developer a few years ago, I managed to get Scrum adopted by my development team for a time.
The whole process worked very well for us - having the team estimate prioritized tasks on a backlog gave us meaningful timeframes to target, and the whole "Managements job is to remove impediments" was great.
The biggest problem was that the process was always perceived - and referred to - as "Bevan's good idea".
While the team appreciated the value we gained, and were happy to continue with Scrum, the Team didn't take the scrum methodology on board as their own. After a while, I got tired of "pushing" and we "fell out" of following the Scrum approach.
Lesson: Make sure the team takes Scrum on board and owns the approach.
We do mostly scrum projects at the customer site. Hardest part in my experience is finding a good product owner in the customer organization:
Too many people think they should be the product owner,
The product owner has a hard time following the pace of the team
Product owner has a hard time getting all the detailed information the team needs
Moving items down the product backlog to add something with a higher priority is difficult
etc.
Training internal teams to use scrums is doable, bringing in your own scrum master is doable, but a good product owner should be part of the client organization. It's harder to train this external person.
Having a proxy product owner, who works together with the customer product owner does help a lot.
I moved from a company that adopted Agile to the tee to another company which follows the traditional methodologies.
Perhaps the biggest difference I have seen is that the second company struggles to prioritize. There is so much work on each person's plate that they fail to deliver on time. IMO, Agile brings about some transparency to the situation and lets the team as a whole prioritize.
A scrum master in the Agile world would take care of fire-fighting and be the voice of the (sprint) team. In fact, in the first company (where we had a separate scrum master and program manager), the scrum master would fight it out with the program manager when the latter makes false promises to the management. Meaning, the scrum master knows how much a team can produce/deliver after a few sprints, which helps her nail down on the predictability of a team.
I also noticed that the R&D resources have a sense of accomplishment at the end of each cycle, and are looking forward to the next one. But then, a good project manager could get this done in traditional scenarios as well.
The biggest issue, as already stated, that I too have experienced is the lack of buy in. It is very difficult to get people to truly become vested in the process.
The other issue, which is also one that directly contributes to the above issue, and also in a large part one of the founding causes of Agile is the lack of management to stick to the outlines of the manifesto of Agile.
In Scrum, Lean, or whatever version of Agile you are working with one cannot break from the manifesto points. If a process is being used to break away from those priorities then most likely the management is screwing up and the buy in will fall apart. The manifesto MUST be followed:
Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Some scenarios might be when a gantt chart appears from one of the above processes for whatever reason. Gantt charts can be useful, but if all of a sudden a developer is reviewing a gantt chart with management, the last point is broken. Responding to change has slowed because encouragement of the plan is being favored over change. Instead a board with stickies should be used, simplify what is on the board with only the current working items and back burner items. This makes changes easy. Once anything is solidified in a "tool" it slows responding to changes. Sure, management needs to record and track things in some ways, but pushing that onto development only slows the responding to change, and pushing tools onto developers (unless they want them for development and can utilize them appropriately) messes up the first point, of the individuals over tools and process.
In another way, don't stop development for the purpose of writing comprehensive documentation. Unless you only have a single developer, then someone should take the documentation load autonomously from the development role. Pushing these things together drastically slows development and for periods of time, can shut down any effort to actually get working software.
The last point, is to always, ALWAYS stay in contact in some way with the customer or prospective customer. Talk to them regularly about what they want. Talk to them daily and show them as much as you can of UI, or even data flow work. Anything that they would understand they should see. Talk to them, educate them about the architecture and ideas going into the application and never forget that you are building the application for them.
Summary:
Biggest issue is buy in. Second is management sticking to the manifesto guidelines.
If you can mitigate these two risks, you should be good to go. Anything else is cakewalk after getting buy in and getting management to understand that they'll need to be truly strong, and non-micro management managers. Specifically, managers might even need to become leads, or fill a different style of role.
...hope I didn't stray off point too much. :)
I have been running Scrum in several projects. The biggest problem, as I see it, is that not everybody in the organization is into the process. Everybody needs to be committed. Not only the team of developers. Often the managers are the persons that initialize the process and expect that things will change to the better without them doing anything.
My suggestion is that you run a workshop with the whole organization so everybody knows how the process works. Not only the developers. It's essential that you have a person that is really into the process. A person that can answer questions the team and organization have. A mentor.
Being agile is about welcoming change. You should not let the process gets in the way of sense. Do things that works for your organization, but you should try out the whole process before throwing something out.
We implemented Agile (set of SCRUM - management and XP - engineering practice) in an environment that was waterfall with large projects in an environment that was heavily integrated. The waterfall police were everywhere. As you can imagine, many projects failed. Having done Agile at a previous employer, we received permission to trial agile for the project.
Internal to the team, we used the Agile practice. Externally, we wrapped the agile practices with waterfall processes meaning primarily reporting. Thus, we looked from the outside like a waterfall project. However, there was a big difference, internally we were using agile and consequently we delivered, on time, within budget with high quality.
The critical success factors were embedded coaches (Iteration Manager Coach, Dev Lead Coach, Test Lead Coach and a Solution Analyst Coach). Securing commitment from dependent system in advance (required that we look ahead to identify depend systems and the work required from those systems) was a must in a heavily integrated environment. Prior to starting, we immersed the technical and business members of the team in an agile boot camp. This ensured that the key players (product owner and technical team) knew there roles and could execute effectively. Finally, the wrapping of the project with waterfall reporting enabled us to tie into all the existing reporting structure in the enterprise.
The net result is that the company is now moving waterfall projects to agile. This is all possible only because we have been able to deliver high quality software at a sustainable pace.
Where I work has been using Scrum for a while now but it seems to have gone through a few phases. In terms of obstacles, one part is to prevent putting in too much change at once and just introduce things slowly,e.g. put in a daily standup one week, a couple weeks later put in a story board, a couple weeks later bring in pair programming. This allows for the various tweaks that will happen to work and if the changes improve things then this can help build up some good momentum. Another point is to make sure that if there should be changes in how something is done that the person being corrected isn't belittled or mocked. At times this may mean that you interrupt someone or that you bring in a "Can we get back to basics?" or something similar to try to put things back on track rather than just yelling at someone or doing something else that is counterproductive.
Bringing in consultants was one of the best things done around here, IMO. Now, these guys came in to help evolve how development was done here. Bringing in pair programming, TDD, concepts like broken windows, organizing project folders, and bringing in mocking for tests, were all excellent additions that while we may have gotten there on our own, it may have taken a long time which wouldn't work out so well.
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.