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 am working in a dev team where we religiously follow agile.
However, I have not had to change how I work (unit testing etc doesn't count as I do that anyway). I mean, do I need to change how or how often I communicate? This soft skill side of things with agile is what I am interested in.
Thanks
If your team is utilizing agile well, then you probably should see some changes in how you work. It's possible that you already developed with a fairly "agile-compatible" mindset, even if your previous work experience was in a more waterfall-style methodology.
Some specific things that I think agile developers ought to be doing (and in a well-run agile team, will naturally find they need to do)
Focus on incremental, complete changes rather than massive architectures - This is a core tenant of agile from the macro planning side, but it's also important to practice even for an individual developer. With a 2 or 3 week iteration, you'll find you simply don't have the time to spend 1 1/2 weeks developing something, and half a week integrating it all together.
Check in early, check in often, and check in working code - Don't do this, and you'll soon find you're that guy famous for breaking the build with a day left before the iteration ends.
Know what's blocking you, and what is likely to block you in the upcoming week or two, and tell people about it - No one in an agile team likes hearing at the last second that a developer working on a critical piece is held up waiting for something to complete his work.
Think about the end of an iteration throughout the iteration - Every line of code you write should be done with the consideration of whether this is realistic to complete before the iteration is over.
Always Be Crunching (hey, I couldn't have a pithy list of advice without a cute, Glengarry Glen Ross ripped off acronym!) You'll learn by your second or third iteration that slacking off for a week followed by some all nighters is going to bite you in the ass.
If you're already following all these - great! They're certainly general best practices rather than being specific to Agile. I think most developers do have a bad habit or two that this list addresses, though (I know I do on occasion.)
In addition to Ryan's great points here are a couple more.
Discuss your ideas with other members of your team. Your fellow developers will quickly point out potential flaws in your thinking and suggest alternatives (be ready to listen and not get offended). I found this works best during planning/story tasking. In a 2-3 week sprint it is painfully obvious when you go down the wrong path. It might even stop you from successfully finishing all you tasks/stories. If others know your plan of attack up front it makes it easier for them to step in and help you out finishing your work if you need it.
Do not hesitate to suggest new ways of doing things. One of the great things about agile is that team processes are not set in stone but evolve from a series of retrospectives. If you have developers who never speak up, the process never changes and things do not get better.
Put your user's hat on. Every application has an end user. Sometimes (especially when you do not have a close contact with your users) you have to step back and question decisions (even if made by a product owner). If you can make a good case, not only your users but the entire team will benefit from it since the product will be better received. Developers do not do this often enough. We want to make things better, faster and leaner in the expense of other, sometimes more important things like delivering on time or adding more features.
I hope this helps.
The specifics of agile will be different for every person you ask. Yes, you probably want to communicate regularly, but you don't want to take it to extremes that keep you (or your coworkers) from being productive.
But like I said, it will be different for everybody. The only people who know how best to match your team are the people on your team. Just tell them you aren't used to agile and you were wondering how you've been handling it. They're really the only ones who will be able to say for sure.
Short answer but was very useful to all developers that asked me that question:
There is a book called Practices of an agile developer,http://www.pragprog.com/titles/pad/practices-of-an-agile-developer.
This book will specifically answer to your question. I like it very much because it's not just about the process, but behaviors and psychology.
Attitude-related things:
1) Good pair programming means making an effort to explain things really well and listening carefully. That's a skill in itself. You have to learn how other people tackle things and be patient when other people tackle things differently from you.
2) Being prepared to be flexible and change your mind. The smaller the ego, the easier and less painful it is to handle this.
3) To do agile well, you need to be communicating continuously with everybody in the wider team (i.e. not just devs - sysadmins, managers, customers, network admins, hardware people...) Part of this is feeling comfortable, safe and confident - i.e. there needs to be real trust in the team, not just phoney trust - real trust
4) Be prepared to work outside your specialism and comfort zone. I often have to pair with graphic designers, system admins and DBAs. Saying "that's not my job" isn't part of agile. We're part of a multidisciplinary team and getting the product released in a useful state is the whole team's problem - not just looking after my pet specialism.
5) Try to keep things simple and minimal - no "we'll make it totally generic" or "we'll need it later". Think "you aren't gonna need it." We're shooting for small, simple, concrete steps informed by feedback.
6) Tackle the difficult things and the things that aren't clear first - so that the you get feedback on the problems as early as possible so you if you have to revise estimates or cancel the work the customer gets informed as soon as possible.
7) Try to keep the team dynamics co-operative rather than competitive. Pitting people against each other pulls the team apart - and it gets you well-polished fragments and a broken product rather than a cohesive whole made by people that give-and-take as they find necessary to be successful.
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 7 years ago.
Improve this question
I have met a lot of people for whom Agile has worked really well, and most of them tend to be managers and architects who plan and delegate the work. However I really haven't found much good developers convinced that Agile is working for them.
Of course you can say if Agile isn't working for you, you aren't doing it right. But whatever remixes of Agile are out there, is it working for you as a Developer? And why? Does anyone else think, within a traditional (or close to) team structure, Agile feels more like a form of micromanagement than self-management?
At my first job, we had daily scrums, wrote automated tests, had automated builds, pair programmed, etc. We had been in the agile groove for several years. And for our efforts, we were rewarded with software that I wouldn't touch with 20ft pole. The quality of our product was atrocious: I'd describe as the piecemeal hacking of 100 amateur developers.
What went wrong:
The company I worked at had a notorious reputation for hiring entry-level developers for the lowest pay ($25-27K/yr was the norm), and frequently we'd outsource work to the lowest offshore bidder. I've heard that agile just doesn't work on inexperienced developers, and I think it showed through the code and our turnover rate.
No documentation of any sort. No functional documentation, no technical documentation, no requirements, no bug tracking. No one ever wrote things down on persistent media: all requirements and bugs were communicated by email, word of mouth, and psychic mindreading.
Lousy testing: our automated tests were invaluable, but QA and UAT testing was a disaster. Since we didn't have any formal requirements documentation, QA users didn't know what new functionality they were testing, so all QA consisted more or less of haphazard end-to-end testing. User acceptance testing was performed in production: we installed the product on our customers servers and reported bugs as they occurred in production.
Crisis-driven development: bugs were handled by using the "OMG WE HAVE TO FIX THIS AND REDEPLOY PRONTO! NOW NOW NOW! NO TIME FOR TESTING JUST FIX IT!" management methodology.
Although we did everything right and really adhered to agile principles by the book, the methodology failed harder than anything else I've ever seen.
In contrast, the company that I work for now uses a waterfall-like methodology, produces a few hundred pages of documentation for each project, has few automated tests but a sizable QA team. Interestingly, the quality of our product is through the roof, and the work environment is orders of magnitude above and beyond the other company.
I know many people have had the opposite experience. As is usually the case, methodologies are not a golden hammer --- you can probably start a successful project no matter what methodology you choose. In my experience on successful and unsuccessful projects, I get the feeling that methodology doesn't matter as much as environment: comfortable, happy developers and sane project managers are all it takes make a project work.
At my company, we made a wholesale switch to agile practices about 4 years ago when a new VP came in. This VP had experienced success with Agile in the past, and decided it was what we needed.
As it turns out, he was right. I was a developer at the time (albeit a somewhat junior one), and I loved the practices. Pair programming really aided knowledge transfer and prevented the formation of knowledge silos. Unit testing, test driven development, and test emphasis in general made for more robust code that wasn't over-engineered. No Big Design Up Front meant that instead of spending 6 months writing requirements documents (by which time the market had passed us by), we were prototyping and delivering real value to customers in a timely matter. Working closely with a customer surrogate (in our case, a technical product manager) greatly shortened cycle feedback time, which helped us deliver what the customer actually wanted.
Our organization had quite a few talented developers, but we were very prone to cowboy coding. A few developers didn't like the new practices ("What do you mean, write tests? I'm a developer!"), but generally everyone loved the changes. Defect rates went down, customer satisfaction rates went up, and our office became very well regarded in our company.
About a year ago I became a manager, and I heavily use Agile practices, incorporating some Lean principles as well (value stream analysis, waste elimination, kanban). Tightening up release cycles has been an ongoing activity, and my team now releases as often as possible (with quality!) - often every two weeks. We have no field reported defects from my team in the past year, and the sales people and product management love the shorter release cycles.
As a developer, Agile really increased my confidence in working with various areas of code (I now feel nervous whenever I'm changing anything in a package that DOESN'T have 100% unit test coverage!), taught me to be a more well-rounded programmer (thinking of test implications, business impacts, etc.), and helped me write simple, self-documenting code. As a manager, Agile and kanban gives me predictability, lower lead times, lower defect rates, and an empowered team. This is not theory, or speculation, or hand waving - our team morale, defect rate, customer satisfaction, and balance sheet have proven that Agile can do wonderful things for an organization.
To comment on the Principles of the Agile Manifesto from my experience at a site that tried it.
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
This was a double-edged sword for my last site -- valuable was taken to mean 100% perfect and bug-free.
Welcome changing requirements, even
late in development. Agile processes
harness change for the customer's
competitive advantage.
I still communicate with that site and just today, their rock-hard deadline date, they were given a requirement change. That was just the way things were there; it's almost as if they wanted failure.
Deliver working software frequently,
from a couple of weeks to a couple of
months, with a preference to the
shorter timescale.
The norm for many years was basically build and deploy daily, hourly, near real-time...
Business people and developers must
work together daily throughout the
project.
Some of the meetings/reviews with respect to this were hilarious. We were reprimanded for not working with the people (because they asked us not to because they were already working 9-10 hour days) and then for bothering them because they were busy.
Build projects around motivated
individuals. Give them the
environment and support they need,
and trust them to get the job done.
Ahh, here's our problem... We had top-of-the-line PCs but the business side wasn't supportive. The positive morale essentially got beaten out of you after about a year or so... This also negates your micromanagement concern (if implemented correctly).
The most efficient and effective
method of conveying information to
and within a development team is
face-to-face conversation.
This worked out well. Personally I prefer email because I hate taking notes.
Working software is the primary
measure of progress.
No doubt here.
Agile processes promote sustainable
development. The sponsors,
developers, and users should be able
to maintain a constant pace
indefinitely.
I agree with this 100%; the problem with the last business team I worked with was the expectation of 30-hour days, 10-day weeks, and 400-day years was not a pace I agreed with.
Continuous attention to technical
excellence and good design enhances
agility.
This is where some developer morale & education was needed.
Simplicity--the art of maximizing the
amount of work not done--is
essential.
I love this one and it's long been one of my goals. However, there was a "if you're not typing, you're not working" attitude that was tough to overcome.
The best architectures, requirements,
and designs emerge from
self-organizing teams.
I agree with this about 90% -- my only caveat is that they must be well-educated and well-informed teams.
At regular intervals, the team
reflects on how to become more
effective, then tunes and adjusts its
behavior accordingly.
We just failed here and it likely caused a lot of other problems we had. The business side was really good at saying "you need to do what we say needs to be done."
To wrap it up, if you're working somewhere where everyone is informed and on board with an Agile methodology, it should be a great place to work. When the goal is great software, momentum alone will carry any project.
Agile has worked awesomely for me as a Developer in my current environment. Here are some practices and why it seems to work so well:
Pair programming - This prevents anyone from feeling an individual ownership of the code. Pairs of developers tend to make better code than one person's "mad science" code that seems to happen if one person writes a bunch of code in isolation. This also allows for someone else to be brought in if someone goes away and that feature or enhancement has to get done while the person is away. Sometimes, one developer may think something will be great but if no one else can understand the code, it is useless to have unless it is perfect and futureproof which isn't likely.
Scrum - This creates both an accountability and communication so that each person knows what the other is doing. If someone wants to know how the sprint is going, just show up at the stand up. The standup is really simple in that it is just 3 questions: What did I do yesterday, what I am doing today and what would prevent me from getting that done?
Test-driven development - A variation on this is practiced where I work in that we generally try to have tests for most of the plumbing code we are writing to customize a CMS in the big project we are doing. This mindset can be tricky to get into though it does get easier as one practices it more.
YAGNI - The "You Aren't Gonna Need It" principle that can really be hard if you've been a perceptive programmer that generally puts in 101 things as a "Well, I might need this someday..." mindset. Another way to put this is a "Keep It Simple, Stupid" idea.
Sprints - The idea here just seems to prevent a sense of being overwhelmed as we are just working for 2 weeks on this or that, and don't look too far forward as it may well change.
Demos - Showing off what we have done, getting feedback on what is good and what isn't is crucial for getting things better and having a mindset that we want "continuous improvement" in the project and what is good enough today, won't be good enough tomorrow and get better at what we do.
IPM, Retrospectives - The ability to look back at what was done in retrospectives is useful for venting frustrations, celebrating things working well and finding ways to address pain points. IPM is where we determine our future for the next sprint in terms of what will be the goals and how long do we think various things will take by using a couple of different estimation tools, one for points on "epics" as we call them and the other for hours on an individual task or card which is part of a story that is something between the epic and a small piece of work.
Storywall and user stories - Now this low tech tool since it is just a few whiteboards, with dividers and post its provides some structure to things. We have lanes for each of the epics and various columns for states of work: Backlog, in development, on dev, or on test. There are also places for the task backlog, blocked cards, questions, standards and practices and a few other things that may be useful for managers to see to get an overview on the current status if they want more of a bigger picture than what they would get at standup.
Broken windows/technical debt/tasks - These are similar in some respects and are useful as a way to illustrate that quality matters,i.e. we don't want broken windows that can be easily explained in non-technical terms by either using a house in a neighbourhood or the New York Subway sytem as starting points. Technical debt being something that doesn't immediately add business value that is sometimes an important thing to use to prevent some problems as there may be problems with a particular architecture and so part of a sprint may be spent doing a re-arch that has to be communicated so that if there is a sprint with little to demo this is why.
I don't know if the idea of a "self-organizing" or "self-managing" team is part of Agile, but it has been a bit of a challenge for me to have enough faith and trust in my co-workers that things will work out fine. The professionals that are the rest of my team know what has to be done, are reasonable, honest people with integrity to just get the work done and not be jerks about getting things done. There aren't egos or bad attitudes which really do help foster building a team.
Agile hasn't worked for me, the main reason being that the systems I usually develop need a well-defined and well-thought architecture, which is hardly realisable by an agile approach. Agile approaches tend to write as little code as necessary to pass the applicable tests, and thus to grow the system organically. This can be nice from many perspectives, but it wreaks havoc from the architectural viewpoint.
From my personal experience, Agile methodology tends to create a huge technical debt in the long term, and while it might save you (as a business owner/management) a couple of bucks short term, in the long term it will come back and bite you. Whatever you do not fix now will eventually cost you many hours of work to fix at a much higher cost than it would have cost you to invest some more hours into the original problem.
Agile is always great from the point of view of beginners and management, but I do not know one experienced programmer who actually loves it. The whole point of Agile is to save development money for a company, it has nothing to do with actual product quality. In fact most of the methodology promotes bad code done quick over well-engineered code. The difference is that a few years down the road, you have to do the whole work all over again whereas the well-engineered code can last decades without corrections. Good programmers do not need Agile methodology most of the time.
We have a business logic library written 22 years ago here by a single team of 3 programmers using waterfall methodology, and that code hasn't needed a single correction since. Because it was tought properly, was well-engineered, and the three programmers took their time and were careful with their implementation. Agile methodology would instead ask of those three to do the strict minimum to make sure some ill-defined tests passed, and then wait until the next time you hit a wall to add some more duct tape code. It's a ridiculous way to work and goes against every engineer fiber in my body.
To this day I refuse to work in an Agile environment, because frankly I do not need it, and I do not need an employer who thinks I do need it.
Agile is not a methodology, it is a subset of methodologies that have a common set of goals, and more often then not those methodologies have wildly varying results based on team makeup, corporate culture, and implementation.
Off the top of my head, purely developer agile practices would include pair programming, TDD, user stories over specs, the assumption that all code is going to be refactored several times (although this is part of TDD) and code reviews more then anything. Things that impact us are daily standups, being engaged with users regularly and directly, postmortem introspections, and very tight development cycles.
I'm a developer and a manager at the same time, so I either have special insight or my opinion is totally invalid. ;)
I will say that Agile means a lot of things. It's actually a whole family of methodologies and guidelines at this point.
Exposing yourself to all these interesting ideas is really the thing. As a manager, it's very hard for me to decree that a whole team suddenly adopt a whole methodology, but if they see me constantly trying to improve every aspect of my game, I think they appreciate that. And hopefully, if they like what they see, they follow my example.
I've managed to slowly implement a bunch of things from Scrum without (hopefully) coming off as a tool. Burn down reports, stand-up meetings, and story cards on the whiteboard have really made us better at shipping software. For instance, on any project tasks are constantly being done ahead of schedule or late. In a really big project, it can become very difficult to tell what that's doing to your ship date. With burn down reports, I can tell what a slip does to our ship date, and if we need to just start cutting features in order to meet a deadline.
That's more of a management thing, but the other devs here care about it because it might mean they get to keep their jobs or avoid a death march. :)
But it's not just management stuff. There's tons in Agile about best practices for source control, unit testing, etc. Just good solid best practices. As an industry, we are pretty terrible about mentoring, so it's good that this information is out there.
From the developers perspective I think it works well. In my point of view agile techniques have in common that the loop between defining the task, working on the task and getting feedback from that task is a very small one as compared to a non-agile approaches.
Take TDD as an example: Code the test, red bar, code the functionality, green bar, refactor, red bar, fix, green bar.
From the managers perspective this faster feedback loop is also true: Daily meeting one, status green, daily meeting two, status yellow, countermeasures / re-assign ressources, daily meeting three, status green.
Immediate feedback and knowing where you are heading gives a feeling of safety.
In the so called 'traditional team', Agile development would increase the visibility of individual developers to management. That would probably allow managers and architects to plan their work better. Ofcourse that could be interpreted as micromanagement.
But from an organizational perspective, if it produces results, who cares.
I guess what makes an "agile" project agile, is the methodology: "Design for today not for tomorrow".
For any not life-critical software systems this is a way to keep programmers coding in stead of discussing ages about design. Please note that design is not scrapped, it is just done in smaller and therefore more overseeable chunks.
All other techniques that are associated with agile, like pair programming, are more borrowed ideas that could also be used effectively in any other methodology.
Now, does this technique 'work'? Yes! If applied correctly, the technique promotes that the software product will be ready for shipping at any time to react to competition.
On the other hand, because programmers are feeling they are coding more, they are generally happier. And they are less irritated by writing specs because this phase is inherently always small.
But again, if you know exactly what your product is going to be and especially if it is life-critical like the space shuttle, agile development is not what you want.
Nearly every management is aware of "Agile" by now: It's this thing, you know? Alone by your initial question I would assume that something is really going wrong. I really recommend you reading a book like Practices of an Agile Developer (as the title suggests - it's about what's in for you).
Some managers read a book and then will know what agile is all about. They are telling you what to do and everything is fine, isn't it?
If you look around, there are a lot of developers (in Agile companies) who can't tell you within a second what the purpose of a stand-up is - and that's an issue. If you (and maybe even nobody else) don't know the why the StandUp won't make things better.
Take a look at time tracking (and time estimation) - there are some managers who think it's about measuring how much work you do: Hey, you have a 40h contract but the time tracking tool says that you have only be working for 38h this week! That's not how it was meant to be used.
The only thing you can do about that: you need to learn what agile methods are out there. Mediocre managers will pick the ones they find interesting. Good managers will grasp the why and not only choose the methods for their direct benefit - but also those which will make the team more happy / efficient / teamish (Team vs Workgroup).
P.S. Something you really need to take care of: In agile there is no place for slackers. Everybody has to do stuff on their own. You have to put personal interest into the success of the product. If you don't do things on your own, somebody will tell you what to do (and then there's micromanagement).
Has Agile really worked? "Yes."
Before there was "Agile Programming" there were equivalent largely unrecognized methodologies. I thought these were called incremental prototyping but apparently this has been split into that and evolutionary prototyping.
I suspect that many or most of the successful systems were so constructed. Just because the methodology grew a new name doesn't mean that it suddenly appeared.
It's just that Waterfall and other broken management techniques that got all the press.
I say Agile works.
I say it's the only thing that ever worked.
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
In your opinion, who should fix a bug? A programmer, right? OK but really, who... let me explain.
I'm a Scrum Master across a number of Scrum projects. Scrum says 'ring-fence your resources where possible', a sentiment I whole-heartedly agree with.
Generally we integrate a certain %age of each sprint to be bug-fixing from the previous sprint(s) - all well and good.
After each Sprint we Demo and Restrospective to our clients, and promote our development code to a UAT environment (our client generally doesn't want a small bit of his project to go-live, but that's up to them - we're keeping our side of the bargain by ensuring we deploy working and testable code).
Once all sprints are complete we have a UAT phase where the client takes a thorough test of the completed software to find any last minute bugs. Now ideally these would have been caught already, but realistically there are a some that only discovered during UAT.
During this UAT phase, not all the developers are needed on the project 100% of the time, and so we like to reallocate them to other projects. However, Scrum says 'ring-fence your resources where possible'.
My problem is, I'm allocating developers to the UAT phase of one project while starting a separate Scrum project with them elsewhere. Not ideal - however, this is a commercial reality at the moment.
I can either:
1) Live with it and have developers fix their own code - and allocate some time (say, 20%) of the developer to the previous project's UAT.
2) Ensure a handover is in place and have 1 or 2 developers dedicated to bug fixing code 100% of the time.
I like 1), but it makes resourcing a real pain in the arse.
2) scares me, I feel developers won't take responsibility over the quality of their own code. I feel there's a lot to be said in ensuring developers take ownership of their own code - and asking them to fix their own bugs is a good way of ensuring quality. Noone likes fixing bugs, so I've found developers generally try and do a better job up front knowing they'll have to fix any issues that are raised anyway. However, 2) is easier to plan and resource. But 2) will take longer, as fixing a bug in someone elses code is costly in terms of time and resource. If it is a complicated fix, it may need the original developer's help anyway, and it will certainly take longer to fix by someone who isn't as familiar with that section of the code base.
What do people think?
People should fix their own code. Take advantage of the fact that no one likes going back and fixing old stuff when they could be writing new stuff. If the developer responsible for the bug can be identified, make sure they are responsible for fixing the problem. This will encourage developers to be more diligent in writing clean code the first time since no one wants to be seen as the person who has to keeping fixing things they've broken. This is true during development as well when someone breaks the current build.
Update: Having said that, I wouldn't necessarily be dogmatic about it. The customer's needs come first and if the person who created the bug can't be reassigned to do the fix, you may have to assign the fix to someone else.
ScrumMasters don't allocate developer resources. ScrumMaster is a role fulfilled by someone on the Team.
That aside, the Product Owner is the "on the Team project manager", and should be fighting to secure the resources that are needed to stablize the product into production.
Engineering practices have to be improved so that the Team(s) are approaching zero bugs. "Bugs" that live past the end of a Sprint have to go on the Product Backlog to be prioritized by the the Product Owner.
This is a very interesting topic, project management is vital and the apprpriate allocation of resources is essential.
One point I would raise is that having dedicated bug fixers may increase the quality of the code. If I was developing code that had my name against it that I knew other people were responsible for I would do everything I coudl to make sure it was good code.
Perhaps a combination approach is required.. You could take a couple of developers on any project - a different pair on each project - and make them resposible for the bug fixing phase outlining that responsibility up front. That way they can ensure they are up to speed as the project goes along as well as a handover at the end. Your resource allocation is easier and the client gets top notch support.
Just a slightly different way of looking at it.
Cheers
Nathan
Your team should NOT be starting new project work until the current one ships. I think most scrum practitioners would argue that there is no place in scrum for UAT (as it was done in waterfall). What you are looking for is called a stabilization sprint and is your last sprint right before go-live. The WHOLE team works on it. Stuff that gets done during this time includes last minute bugs, GUI beautification tweaks, roll-out documentation, help guides, operations training, and long lunches. It is also potentially a great time for the team to learn something new on their own without the "pressure" of delivering backlog items or to unwind a little before starting something new. Based on your customer's UAT timeframe expectations; if it tends to be on the longer side; you might also put off non-customer facing tasks to this sprint such as log monitoring, server setup scripting, maintenance screens, or other misc tool building.
Whatever you do, don't do any work outside of the Sprint boundaries. It is a slippery slope into waterfall-esque scheduling oblivion.
I think bugs should be fixed by the original developer. Making developers to fix bugs in code that was written by someone else could take a lot more time and moreover could make them demotivated since fixing bugs is not that very exiting.
I vote for #2. As a developer I hate context switching and that's what you essentially impose with #1. As for the code ownership issue, having developers own pieces of code is an anti-pattern. Strive for shared ownership: introduce pairing, rotation etc.
To second #kevindtimm's comment, UAT is just another sprint. Perhaps w/ less developers.
On the other hand, the core of Agile Software manifesto is to deliver business value incrementally, so ideally you're supposed to push to PROD at the end of each sprint. If so then shouldn't UAT be part of every single sprint. Isn't that what the Demo is for?
I really don't like option 2) because:
It gives people the feeling that the job has been done while it hasn't (it's not DONE, there are bugs),
I think people should be responsible for the code they wrote, not others,
I don't think that "bug fixer" is a job, you are not respecting people when doing this.
So option 1) has my preference (but please stop talking about resources and resourcing).
Finally, a little quote:
If you have separate test and fix cycles, you're testing too late. --M. Poppendieck
Yes, I know, it's easier to say than to do... but nevertheless, she's damn right.
I am a lead developer in a Scrum driven team. The way that we tend to work it in my organisation is this:
Before the starts of a sprint each developer will be allocated a percentage of how productive we think they are going to be during the sprint. For example a more skilled more experienced developer will probably be able to be productive 70-80% of his total time during the sprint. This gives time for unexpected meetings, bug fixes. I will come onto the bug fixes in a moment. We will get the estimates for all the tasks signed off and then plan the developers work.
Going into the sprint the developer will carry out his planned work and complete his own testing. If Possible as each block of work is completed another testing phase will take place either by the Scrum leader or the product owner (project manager) just to make sure that there isn’t anything glaringly obvious that needs to be looked at. Anything that comes up in this testing phase goes straight back to the developer that wrote it to complete in the sprint. The way we see it is that the team has effectively committed to completing the tasks given to us at the beginning of a sprint so we needs to complete them one way or another.
If an urgent bug comes into the team and it has to be done right this minute then myself and the scrum leader will take a view on whether or not it it is possible to get it done without effecting the planned work depending on how well we are doing. I.E. if we are half a day ahead of schedule and the estimate on the bug is half a day we will do it without changing the planned work. If that’s not possible we go back to the product owner who decides what it is that has to be pulled out of the sprint.
If a non urgent bug is assigned to the team part way through a sprint then the product owner give it a priority and it will remain in our pot. When the product owner then comes up with our next set of objectives he will prioritise the bugs and the project work together and these will become our planned items for the next sprint.
The thing to note is that it doesn’t matter which project the bug came from. Everything has a priority and that is what needs to be managed. After all you only have a certain development resource. When it comes to which developer does it that depends on several things. you don't always know exactly whose code introduced the bug. Especially if it’s from a very old project. If the same developer can fix it then there is obviously a time benefit there but that exact developer might not be available. The way that we try and work it is that any developer should be able to work on any given task. In the real world this isn't always possible but that that is always our end goal.
I realise that I have been beating around the bush here but in answer to your question about who should do the bug fix in short this is what I would say:
If the bug is identified during the same sprint that the work was being done then send it back to the original developer.
If its urgent then it has to go to the best person to do the task because it needs to done as fast as possible. That might not be the person that originally wrote the code it might be someone with more experience.
If you have prioritised and planned the bug then you should also have time to work out who is the best man to do the job. This would be based on the other work that needed doing, the availability of developers and your general judgment.
With regards to handovers these should be fairly minimal. At the end of the day your developers should be writing code in a way which makes it clear, clean and obvious to any developer that has a task to revisit it. It is part of my job to make sure the developers on the team are doing this basically.
I hope that this helps :)
Part of this falls onto the Product Owner to prioritize if some bugs are more important than some cards to my mind. If the PO is, "Fix these bugs NOW," then there should be bug fixes moved up to the top of the list. If there are numerous high priority bugs then it may be worth having a stabilization sprint where bugs are fixed and no new functionality gets done. I'd be tempted to ask the PO how much time they want spent on bugs though I'm not sure how practical that is.
The idea of having maintenance developers is nice but have you considered where there may be some pain in having to merge code changes from what maintenance does and what those developing new functionality do? Yeah, this is merely stepping on toes but I have had some painful merges where a day was spent with 2 developers trying to promote code due to so many changes between a test and dev environment.
May I suggest the idea of another developer fixing the bug so that someone else picks up how something was coded? Having multiple people work on some feature can help promote collective ownership rather than individual ownership of the code. Another part is that sometimes someone else may have an easier time with a bug because they have fixed that kind of bug before though this can also lead to a dependency that should be checked regularly.
Why not capture a backlog item called "bug debt", and have the team estimate it each iteration. That item will be used to hold some developer's time to fix it (as in #1).
I'm also a little concerned about the bugs that appear in UAT. Would it be possible to have some of those testing folks on the teams to catch them earlier? This kind of thing is very common in projects where it's thrown over the fence from group to group. The only way I have seen that works is to integrate those other groups into the teams and rethink the testing strategies. Then, UAT does what you want it to do... capture usability issues and requirements. You're right they won't go away completely, but they will be minimized.
I think people should fix their own code as well. Why waste all the time with handovers?
It might be worth doing UATs as and when each feature is complete; so the "testers" working along side the "developers" testing functionality as they go. The testers should be able to run through the UAT criteria.
If there are more issues within the UAT with the stake holders, then they are change requests or the acceptance criteria is probably ambiguous in the first place!
I've generally followed option 1. Often because resources go to other projects. If you do root cause analysis by discussing how bugs were created, there's a small side effect of public embarrassment. If you've instilled any sense of ownership on a project, your developers should be more than a bit embarrassed if their code is displaying a higher percentage of bugs than others or what is reasonable.
I typically find that in these cases, most developers are actually frustrated if their too busy to fix their old bugs. They don't like it when somebody else has to clean up their mistakes.
Instilling a sense of ownership and pride are critical. If you haven't done that, you are always counting on the threat of punishment to get them to do the right things.
Always try to have the original developer fix their own bugs, IMHO. This part is easy. If you've got a few developers who behave unprofessionally and shirk their duty to produce high quality software, give them the boot. If the problem is cultural, read "Fearless Change" by Linda Rising and get to work in your SM role as change agent. I'm right there with you, so this isn't me just beating you over the head; I'm doing the same thing at my job :).
However, you've got bigger problems.
You're a Scrum Master allocating resources? Yikes. The Scrum guide calls the SM to
...[serve] the Development Team in several ways, including:
Coaching the Development Team in self-organization...
I understand we all don't have the ideal organization within which to practice Scrum; however, this should gnaw at you daily until it is improved. The Scrum gude puts it simply:
Development Teams are structured and empowered by the organization to
organize and manage their own work.
**Second, stop saying resources. Just stop it. Resources are coal, wood, and natural gas. People are not resources.**
Third, this UAT is a big impediment to the Scrum team. If I'm understanding you correctly, the client has a giant, red button they can press and completely blow up "Done" work by saying, "You've got to fix this before it's finished." Any Scrum Teams subjected to this no longer have velocity, forecasts etc. These things all measure "Done" and potentially "Done" work; they depend on "Done" software that is potentially shippable. Heres how the Scrum guide describes the Product Increment:
The Increment is the sum of all the Product Backlog items completed
during a Sprint and the value of the increments of all previous
Sprints. At the end of a Sprint, the new Increment must be “Done,”
which means it must be in useable condition and meet the Scrum Team’s
definition of “Done.” It must be in useable condition regardless of
whether the Product Owner decides to actually release it.
You can improve this UAT situation in several ways:
Convert the client's UAT to a simple feedback loop i.e. feature requests come out of the UAT, not notifications of incomplete software.
Get their UAT testers to work alongside the Developers during the Sprint and make sure the work is "Done."
Do not take work into a Sprint unless a UAT person is available to validate the work is fit for purpose.
I realize none of these will seem "commercially" plausable, but you're the SM. If no one else in the whole organization is saying these things, you have always got to be willing to.
I realize this sounds like a kick in the pants, but you need to year it from someone. This is a bit like the old shoe / glass bottle scenario from (wow) 10 years ago now.
Please feel free to reach out to me if you want to explore this further. I'm a fellow Scrum Master, and would be happy to help you work through this tough scenario.
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 11 years ago.
I'm dealing with an issue with my current employer that has seriously made me consider seeking employment elsewhere. They are under the impression that 100% of custom development should be eliminated and replaced with COTS products, such as SharePoint. While I realize that this is not a realistic expectation, I've found it impossible to argue my points with the people in management that share these views. Their argument usually involves something along the lines of a feature already existing in SharePoint that covers feature X, therefore there is less risk involved and testing doesn't have to be done against it.
Case in point, we have a situation where a SharePoint list is completely incapable of meeting customer expectations and requirements. Saving this data in a SQL database, however, would easily satisfy the requirements. Any time our development team suggests going outside of the boundaries of SharePoint, however, management goes up in flames about how every line of code adds to the complexity of the project and increases risk. While this is certainly true in some situations, it's not always the case. Their argument, however, is that since SharePoint provides a mechanism for storing data, that we should use it 100% of the time. Regardless of if it meets customer requirements, or not.
I've gotten to the point that I hate coming to work because I'm constantly forced into doing things that I know (with 100% certainty) are not right and that could be made right by doing custom development. It's simply what seems to be an impossible argument where I work, however.
Have any of you experienced a similar situation? If so, what have you done to work through these challenges?
If you don't share the vision of the company and if you can't enlighten them then sure, it is a good time to start looking.
Have you pointed out that there is risk in forcing a "solution" on a client that does not help them or is missing functionality or is unusable?
Perhaps come up with plans to address and mitigate their perceived risks.
You document your concerns and let those above you know them, and then you do as they ask. If it doesn't work, you have documentation that you brought the concerns up. But try to make it work their way, so it doesn't look like you're trying to undermine their plans. They're taking the greater risk, and thus they get the greater responsibility. Try your best to make it work their way, and quit worrying about it.
This may sound bad and may not be the answer you want. There is a little known division in my office called "The Skunk Works." People, on their own accord (usually during lunch breaks or compile time) decide to write little programs that help the company. The fun things about this is the result doesn't "cost" the company anything.
The conversation usually goes like this:
"We need to buy this software" -Boss
"But, we have had that thing for months. John, wrote that back in the day" -Programmer
"?" -Boss
A lot of times the developers see a decision as being bad and just create a parallel process that happens automatically. Then, when the stuff hits the fan and the customers are frustrated, the alternate solution is ALREADY in place.
I have an example of an auto release machine. Developers used to create these custom reports. As our customers increased, the developer's workload increased. The problem was "In order for the customer to get the custom report developer had to be involved." So, while the company was looking into hiring someone to do reports full time or to find ways to have the customers do them, I wrote an auto release machine that looks for report changes and releases them directly to the customer. I also wrote a utility that allows anybody to make changes to the reports that was easier to use than what the developer has. When the Boss made the announcement of trying to find a solution, I told him that it was already in place and that even he could make changes to reports and get them released. Now, everybody can change reports, usually it is management and customer support who make these changes. The fun side is that developers arn't involved anymore.
Just do it. If you're going to quit anyways, might as well try.
Does someone in management own stock in SharePoint? Was the system developed by the CEO's younger brother?
If they are that resilient to change, you should find out the real reason before trying to argue with them. They may claim that there is added complexity, difficulty testing, etc, but if you can counter every argument with one that shows their position, with all due respect, to be misinformed, and they still won't discuss, then you may be arguing the wrong point.
If they are locked into the technology because of a non-technical reason, such as someone once read that SharePoint is the ultimate in any technical situation (and, of course, had no clue what the article was talking about other than SharePoint = good) then you shouldn't bother trying to argue and save your energy. For the job hunt.
Prove it to them. When the requirements ask for a list that can handle 100,000 items with a multi-column sort - write a script that adds 100,000 test items into a sharepoint list and let them try it, preferrably with the "customer" requesting the list watching. :-)
I would definitely get my resume out and into the open if I were you. Not only is the experience that you are currently having frustrating, it can really hurt your career development over the long haul. Just think about it. While you are languishing with your current employer in your current position, other developers are adopting new technologies and expanding their experience.
There is such a thing as ideological differences between developers and what a company's idea of a role for a developer is. If open discussion and candor get you nowhere, you will not be faulted for a lack of effort. Loyalty to a company is a good thing, but the relationship needs to be a two-way street.
Sadly, the will eventually probably come to realize that they are wrong in their assumptions - but you can not wait for that day to come. Sometimes it never comes. In particular (and don't get me wrong, I love SharePoint when it is used for what it is intended for), SharePoint is become the next Access, in that people who read management magazines see enough of it thrown around to call it the messiah.
I find that there is typically no way of 'winning' these debates through talk alone. Many managers form an opinion of a product or solution through reading management oriented articles. See if you can find some counter-articles.
If you can cite examples of things which SharePoint is incapable of doing, and show examples of how you can cost effectively solve these problems through custom development then you are well on your way.
The mistake is to try and make this a conversation about technology, it's not, its about efficiency, cost effectiveness and maintainability - those are the mantras and metrics which will sway non-technical managers into considering alternatives.
If you can put together a proof of concept for some of these issues so much the better, eye candy really helps to sell outside of technical teams.
Finally, good luck :)
I am doing the same thing at my current job, there is no easy way to deal with this kind of situation. All I have been able to do is swallow my arguments, cause they have gotten me no where, and do as required by my management. This off course will go against your basic programmer nature of using the best solution for the task at hand, and maybe getting to build something cool in the process, but since they are the boss it is really your only solution. You could try to site cases, with evidence, where it makes more sense to use custom solutions. But if you boss is anything like mine, it won't get very far before the screaming match begins. The only other solution is dusting off that resume and finding a new job.
I have faced the same kind of challenges right from day one. Management have a natural reluctance to add custom code to the solution. However in most cases it has been posible to explain than the right solution for the customer would include some custom code.
Remember, if you argue that you can include the custom code in the common codebase, then the boss might approve the idea.
I really feel your pain.
If it was me I would use my spare time to collect information that proves my point and document it in a easy to understand way.
If they only understand money, talk money, if they only understand fear (doing "this" because they are scared of "that"), use the fear, finding scary thing for them in "their" solution.
Document every new implementation, the time, money and problem that arises. And document what your solution would be instead.
They probably doesn't see the problem in their solution, because they focus on not having problems in "your" solution.
I have worked in a place where management were not constructive in their approach, not quite as bad as you describe, but bad enough.
There are a couple of options. One is to go ahead and do what needs to be done for the client with the best "value for money" option you can. You will probably have to get the developers together as a team to make this "civil disobedience" work.
A more forceful approach that will really make the shit hit the fan is to go to the client (don't do this if it is an external client or if you wish to keep your job) and lay out what is going to happen to this project if X and Y. This is pretty much telling tales out of school and is going to be bad, but entertaining.
A slightly better way is to go up the chain and get a sponsor who can make shit happen for you. Essentially go behind your boss(es) back. This may work, but it is going to have predictable results for your relationship with your management.
Last and hardest is to identify the person who holds the view that any custom code is bad and engage them in conversation to find out where they got the belief and counter that with examples. Emphasis on conversation as you will have to listen to and understand their underlying concerns (which won't be about custom code per se) and only address them after you gain that persons trust.
I cannot tell you which way of doing things is going to work best because it depends so much on the individuals involved. All I do know is that you cannot change people and in my experience the best way to solve the problem so far has been to leave and work with people who are not so...
how about not calling it custom code. If instead you call it 'anticipated SharePoint user extensions' or something it may soften the misconception surrounding a specific term.
also, as has been said, there may be other hidden from you reasons that management is pushing this agenda. It is probably best to not second guess these too quickly, as many would be valid.
Finally, there are alot of places that need development. it doesnt hurt to look for a better match.
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 8 years ago.
Improve this question
I'm the second dev and a recent hire here at a PHP/MySQL shop. I was hired mostly due to my experience in wrangling some sort of process out of a chaotic mess. At least, that's what I did at my last company. ;)
Since I've been here (a few months now), I've brought on board my boss, my product manager and several other key figures (But mostly chickens, if you pardon the Scrum-based stereotyping). I've also helped bring in some visibility to the development cycle of a major product that has been lagging for over a year. People are loving it!
However, my coworker (the only other dev here for now) is not into it. She prefers to close her door and focus on her work and be left alone. Me? I'm into the whole Agile approach of collaboration, cooperation and openness. Without her input, I started the Scrum practices (daily scrums, burndown charts and other things I've found that worked for me and my previous teams (ala H. Kniberg's cool wall chart). During our daily stand up she slinks by and ignores us as if we actually weren't standing right outside her door (we are actually). It's pretty amazing. I've never seen such resistance.
Question... how do I get her onboard? Peer pressure is not working.
Thanks from fellow Scrum-borg,
beaudetious
While Scrum other agile methodologies like it embody a lot of good practices, sometimes giving it a name and making it (as many bloggers have commented on) a "religion" that must be adopted in the workplace is rather offputting to a lot of people, including myself.
It depends on what your options and commitments are, but I know I'd be a lot more keen on accepting ideas because they are good ideas, not because they are a bandwagon. Try implementing/drawing her in to the practices one at a time, by showing her how they can improve her life and workflow as well.
Programmers love cool things that help them get stuff done. They hate being preached at or being asked to board what they see as a bandwagon. Present it as the former rather than the latter. (It goes without saying, make sure it actually IS the former)
Edit: another question
I've never actually worked for a place that used a specific agile methodology, though I'm pretty happy where I'm at now in that we incorporate a lot of agile practices without the hype and the dogma (best of both worlds, IMHO).
But I was just reading about Scrum and, is a system like that even beneficial for a 2 person team? Scrum does add a certain amount of overhead to a project, it seems, and that might outweigh the benefits when you have a very small team where communication and planning is already easy.
Without her input, I started the Scrum practices (daily scrums, burndown charts and other things I've found that worked for me and my previous teams (ala H. Kniberg's cool wall chart). During out daily stand up she slinks by and ignores us as if we actually weren't standing right outside her door (we are actually). It's pretty amazing. I've never seen such resistance.
Question... how do I get her onboard? Peer pressure is not working.
Yikes! Who would ever want to work in such an oppressive environment? If you're lucky, she's sending around her resume and you'll be able to hire someone who is on board with your development process.
Assuming you want to hang on to her, I'd turn down (or off) the rhetoric and work on being a friend and co-worker first. If the project is a year late, she can't be feeling good about herself and it sounds like you aren't afraid to trumpet your success. That can be intimidating.
I know nothing about Scrum, however. I'm just imagining what it would be like to walk around in your co-worker's shoes.
beaudetious, buddy,
I would really suggest you read Steve Yegge's blog called "Good Agile, Bad Agile". It's an oldy but a goody, and I think it's a must read for anyone - like myself about 2 months ago - who gets a little let's say "over-eager" to agile-up their workplace. Agile offers a lot of good practices, but you have to take them all with a grain of salt and adopt what you're lacking and skip out on all the other crud that might be unuseful for a particular situation - e.g. the daily scrum. If your co-worker would just like to code in quiet (read Peopleware for why this is a good thing) and she's being a productive team member quit bugging her with your scrumming a let her work in whatever way she likes most.
People are usually less "hostile" about these practices if you just approach them and simply say "Do you have a sec? Listen, communication is really a problem right now, I feel like I don't know what you're doing and I really don't want to step on your toes again and spend two days writing something you already did like last week, so let's work on this. I'd like to try X, what do you think?". Be compassionate and don't tolerate "bad apples", that's literally how I agiled up my workplace, and many problems have started evaporating. We're by no means an 100% XP or 100% Scrum compliant place, because we just use whatever works and was needed.
Simple. Don't talk about scrum. Don't use scrum on her. Instead take the underlying principles of scrum (e.g. the purpose as opposed to the application) and create different approaches that accommodate her way of working but have subtle tints of scrum.
All humans are different and a lot of programmers dislike scrum. I wouldn't force it upon them as that would just be counter-productive. I'd suggest identifying the problems in the development process (in a non-scrum fashion), see if you can get her to agree that the issues exist, then ask her what she thinks would be a good solution. Her co-operation and input into the process is essential to her co-operation, if she doesn't have buy-in she wont become a citizen.
From there on in you can hopefully create some sort of quasi-hybrid scrum + her approach to the process where you can both agree on the way forward.
I think the key would be to help her understand why you are doing Scrum in the first place. I guess you have your reasons, so why not tell her? You are likely to get resistance towards any change if the people involved don't understand why there is change or what they will benefit from it. If you can explain your reasons for using Scrum, and the following benefits, to her in a way that relates to her everyday work, I think she is more likely to adapt a more positive attitude towards it.
If she sees no value in the Scrum process, or doesn't understand how it relates to her, she probably won't care about it.
I think one of the most important concepts for someone to understand regarding Scrum is the fact that you are working as a group and commit to your project as a group, not as individuals. For many people, this is the hardest thing to grasp, since they are so used to living in "their own World".
I'm not sure Scrum is the central issue here; I'm guessing she feels threatened by the new guy bringing in a lot of new ideas and stirring things up. I've been in that situation before as the new person bringing in a new perspective on things, and sometimes it's just difficult to immediately bring those existing people around to a new way of thinking. It often requires a culture shift which doesn't happen overnight.
Try to get her input and opinion on things as much as possible, and try to show that you respect that she has been on the team longer than you. If after a while she still doesn't participate, then all you can do is mention it to your Manager and let them take it from there.
Continue your efforts to involve the other developer. Remember you are the one who wants to make this change. Ask for help with problems you have. Invite them to the daily stand up meeting. I currently do the planning for the daily stand up and I make sure all the pigs and chickens are invited. If you are the lead on the project it is up to you to address the situation and take a risk. Put yourself out there.