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 5 years ago.
Improve this question
I'm sure that all of us have had to deal with telecommuters at some point in time, and I'm facing a situation now where my new project will have a "core" group of office workers and some off-site telecommuters. Not wanting to repeat past mistakes, I'd really like to know what ways people have tried in the past to effectively integrate telecommuters in an agile process, namely scrum.
My first fear is that the telecommuters will be the first ones to break the "daily scrum" routine. And, as human nature often goes, once that gets broken, it's hard to resume and get people back on track. Scrum recommends enforcing small, fun "penalties" for people missing or being late to the daily scrum, like donating a few bucks to a jar which would later be used to buy a case of beers for the end-project party or something. This is obviously something that would be difficult to enforce online.
The other big problem with telecommuters is the "out of sight, out of mind" problem. Aside from using webcams/skype/teleconferencing, what other tips do people have for keeping the team as closely knit as possible?
Also, what about dealing with telecommuters from different timezones? At the moment, we're lucky enough not to have this problem, but it's definitely a possibility at some point in the future. How have other teams dealt with this problem?
Instant messaging really helps with the "out of sight, out of mind" issue as their 'Status' (Available, busy, on the bog, etc) is visible to all. Also, by responding to messages they reinforce the idea that they're generally available.
I wouldn't worry about the Scrum meeting issue, joining a meeting via teleconf is often easier than attending in person.
Set the ground rules upfront. Don't be wishy-washy about them.
You've probably eliminated the "I got stuck in traffic" excuse for missing the meeting or whatever when they're working from home (or a satellite site) and so there's no reason to expect less out of them.
Take advantage of technology:
Use IM. We use it here and it is great for 'reaching out and touching' the guy four states away. Make it a requirement to be available via IM.
Use other tools to help break down the barriers. It'll depend on your situation.
If you're having the daily meeting, it should be clear to everyone that you're going to be asking the questions:
What did you accomplish since we
last met?
What are you going to be doing
today?
What's in the way that needs to be
moved?
Just because you can't see Matt in his cube doesn't give me a right to be lazy or unproductive and unresponsive. It's like dealing with my kids - let them know the rules and what is expected, then nobody can claim ignorance.
We have success using this tools:
Assembla for project management (source control, wiki, scrum tool)
Skype for voice communication
Google talk for im
We are team of 3 developers, in 6 time zones range.
I spent a year as the only remote guy on an Agile team. I called into a conference line for the daily scrum, as well as the planning/review meetings. I kept in contact during the day via IM/e-mail/phone.
I think it worked pretty well overall. The biggest constant drawback was not being able to see the physical whiteboard we used to track the scrum. We discussed moving to some sort of online tool to do this, but it never happened.
I was one timezone away, and I just considered it part of the telecommute tradeoff that I would work the hours that the rest of team kept.
As far as penalties for missing SCRUM - to a certain degree you should enforce this loosely, via the beer jar or whatever. But if someone is consistently missing/late required meetings, then their manager needs to address that.
The are a number of techniques that you can use - remember the purpose of colocation is to encourage collaboration and communication. A few things can help out.
If your team is all nearby - think about having core days of when everybody can come into the office. My current team allows working from home on Mondays and Fridays - and everybody comes in the office Tuesday through Thursday
For distributed teams, I have had good success with using Wikis instead of giant sheets of paper on the wall. The nice thing about wikis is that they encorage the team to edit the forms to meet the needs of the team as opposed to adapting to a more formal tool.
Another advantage of having a Wiki is each person can have their own page to share pictures about their vacations and hobbies - this makes remote people more real.
When you have a distributed team, I want to second the use of Instant Messaging that includes a status (Available, Away (grabbing a cub of coffee), Busy (in a meeting)) - these can include notes if people switch between working at home and at the office.
Webcams are inexpensive and valuable tool
Invest in a decent speaker phone (we like Polycom phones) for your group conference calls
Use tools like LiveMeeting to promote remote pair programming
A technique for doing stand ups over the phone is to have the person talking say the name of someone else in the group who has not gone yet - this keeps everyone paying attention.
For iteration (sprint) planning meetings - follow up with meeting minutes or a communication plan to make sure that everyone is on the same page. Not being colocated means a tad more documentation and intentionality on communicating.
Good luck
SCRUM and many other agile methods really do depend on physical proximity - it is hard to integrate telecommuters into any development process where integration happens frequently, but these particular processes are especially hostile to disembodied developers.
You will have to adapt the processes to the situation at hand. Video conferencing using webcams is actually very usable, and in fact yo might want to experiment with having their webcam on all the time in their cubicle/work area so people can just walk up and ask a question as they would with any other coworker.
But at the end of the day, you simply have to expect things to go differently for them - they aren't going to be able to fully participate in many processes if you are an agile shop.
-Adam
Make sure they attend the daily standup via webcam; as you said that's the first mis-step down a slippery slope. We try to have all meetings done with a RoundTable as well which really helps.
I've been doing this for two months (working in Canada with the core team in Dublin) and so far everything has been going really well.
See Scott Hanselman's writeup on his first year working remotely at Microsoft - definitely some good tips there. One Year Later.
Instead of a beer jar, the privilege of telecommuting itself could be part of the bargain for participation when required. If the team is not responsible enough to telecommute properly than they probably shouldn't be. More fun penalties for occasional tardiness could be to use a funny avatar to represent the person that is missing from the meeting.
Other methods of keeping people closely knit is using collaboration tools such as Wikis and project tracking tools such as Basecamp or FogBugz.
For differing timezones, early meetings will need to occur based on the furthest west time zone, unless one is on the opposite side of the world, which is a bigger problem. Then it will probably be based on who is in charge.
We have been able to manage daily scrums in our environment even with distributed teams over the phone.
It helps to use software such as Rally and Basecamp to manage the process.
One place I worked used Asterisk instead of a normal phone system. It worked well because when you are working from home, you simply log on, people can call your direct line number, outsiders don't need to know. Even though phone call cost are relativity trivial these days, having a 'always on' connection encourages more communication. The sound quality is better too.
For telecommuters/distributed teams, I recommend getting a decent phone - most desk phones lose the ability for folks on the other end to hear folks who are multiple feet away from the phone during a standup.
When you do your demos of working code for stakeholders at the end of the iteration, use webex or livemeeting or something to share the desktop and a camera to show the speaker so that your distributed participants can see what's going on. (Even better would be to ask your telecommuters to attend during iteration boundaries to participate in person).
I recommend getting folks together for a few weeks at the beginning of the project during the inception/kickoff phase so folks can build interpersonal relationships. It's amazing how helpful the face-to-face interaction up front can be to build a foundation for teamwork.
Use a distributed card wall. I like Mingle (http://mingle.thoughtworks.com), but I haven't used other tools, so can't comment on them.
For retrospectives, it's useful to have a proxy in the room using IM to communicate with your distributed team members... so that any comments the distributed folks have can be written onto a piece of paper (or post-it, or however you do yours).
As for your fears of "out of site, out of mind", my preference for things like this is to not create solutions for problems that have not yet materialized. If you find that your team is becoming disconnected (prime discussion points for retrospectives), then you can facilitate a team discussion on how to deal with any issues that arise. Again - the team should help identify the problem and the solution rather than having a manager or scrum master dictate solutions. Start with an assumption of trust.
Distribute Scrum requires good preparation. It is not just about the tool.
We supported many rollouts in distributed environment and there was one fundamental point - people.
The most efficient is to start with ALL people in one location. They have to meet in person so they can know each other as persons, not just someone virtual on the other side of the world. As I used to say - team members need to smell each other.
For release planning meet at one location, if possible. Change locations so you visit all of them, to have a context and understanding of culture, habits, persons. For sprint planning use video meetings, screen sharing etc. It is not necessary to travel (it would be too often).
Clear roles and team(s) organization must be established. You have to have Product Owner and Scrum Masters. You should consider if you do not want to get PO & SM as close to the team as possible. Definitely you have to get them into face 2 face meetings (it is about face, not a location) every day.
Definition of done, if agreed by the team, helps to have the same understanding what Done means. In distributed environment is a must.
You will need a good communication tools for daily stand-ups . We found usable to use Skype or Office communicator for dailies. We use audio AND chat. Especially in international environment chat allows you to understand people. Keep communication channel open after daily so team members can discuss what is necessary outside of daily report.
And, the most important, is to do regular retrospectives with all team members in all locations. Do not forget to implement ideas coming from retrospective. Teams in other locations will need a local support who will help them to implement ideas.
I work on a team of 5. We to facilitate our telecommute workplace we use:
Asana - Project and Task management
Google Talk + Your favorite IM
client (I used Pidgin)
RingCentral - VOIP Telephone
Gmail - asynchronous communication (i.e. email)
Dropbox - file transfer and
backup
Team Viewer - Screen Sharing, Training, and Presentations
Even with these tools it is easy to fall short on your process so it is important to establish some best practices for your team based on your dynamic. For example, we have two chief practices:
Communicate Often - because we are not in the same location when communicating it is easy to forget that you are working on a team. For our team, we update our tasks in Asana with comments describing ideas, obstacles, and task completeness. When immediate assistance or feedback is needed, don't wait, seek assistance via IM or email if (the person is offline).
Lean on the side of over communication - This pertains more to Asana comments and emails. However, in general we found it is better to give more information than is needed (within bounds).
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
Everyone is talking about Agile and how good this is. There are several advantages and disadvantages of Agile. I have studied them theoretically. Since there are experts here who have worked in many projects I want to know real two-two scenarios where Agile is unsuitable and suitable. Thanks
If it is possible to do agile well, then i believe that is always a good thing. If it is not possible to do it well, then i believe that it can be harmful. Not because there's anything intrinsically hazardous about agile, but because it would mean using a dysfunctional process.
So, agile is unsuitable when the conditions for doing it well do not exist.
Some things that could scupper the adoption of agile:
Team members do not understand the process, and do not have either the time or the inclination to learn it
Team members do not have the experience or maturity to assume more control over their own process
Management requires detailed long-term plans as a deliverable
The customer is unwilling to provide feedback on incremental releases before the final ship
There is a high churn of members in the team
The technology in use does not permit a build and test cycle of a useful length (i've done agile with a three-hour build and test cycle; this was very painful but just about doable), or does not permit it at all
The problem domain does not admit incremental development of a solution (i'm not sure if this is ever true; the nearest i've come to this is when dealing with cryptography, where the thing either works completely or doesn't work at all)
To some extent, these can be remedied. An uninformed or inexperienced team can be shepherded by a cadre of informed or experienced members. Team leadership can write a long-term plan, then let the team ignore it and hope that delivering working code will pacify management. Business analysts or QA can act as a proxy customer for providing feedback on incremental releases. Branching strategies and build servers can be used to decouple build-and-test from commit and merge. These remedies are certainly not guaranteed to succeed, though, and if the problem remains insuperable, agile will not be succesful.
Agile may be unsuitable when:
it threatens to expose overgrown management (some positions suddenly become clearly superflous)
people actually don't want to have fun and do creative things, preffering 9-17 mode of mundane work (maintenance of legacy crappy software that just cannot wait to be disposed of)
politics rather than professionalism run the company
Human Resources run the company (Agile is about humans, HR treats them as things)
the customer expects that you will figure out what he needs for him (Agile will make you asking him questions that he doesn't want to answer)
Agile is expected to be a magic wand that will solve problems without anyone changing their habits (another buzzword, a fad)
development is spread across multiple locations far away from each other, in different time zones (communication suffers)
you have a pointy-haired boss ;)
or in general:
it is misunderstood
organization is devoured with serious patologies
no one actually wants it
I worked with many different teams trying to move to agile. Some succeeding, other which did not succeed. Based on my experience, I can say that:
Moving to agile is suitable when the software creators want to improve quality of their product(s) (whatever its mean in their context) so badly that they are even ready to work as a team to achieve it.
Moving to agile is not suitable when everybody is happy with the current quality level and/or do not want to work as a team.
Sort answer:
agile is suitable, when IT company is making its own product. e.g. visual studio is made in agile way couple of years. And you can see much better "idea to delivery time".
Agile is not suitable for Internet Banking. Another example is client based in US and dev team or its part in azia. The time delay makes things complicated.
Long answer:
First, if you want to run an agile project, your management should understand it and processes in your company should embrace it. If you try to workaround them, you will fail. See how management and internal processes are important here: https://www.youtube.com/watch?v=4u5N00ApR_k It's more important that the management and team leads understand agile processes than the programmers. Usually, opposite is true.
Second, your client's management and processes should embrace agile processes. A bank or financial institution will never sign an agile contract. Their processes requires deep planning and approval at multiple levels. See how clients misunderstanding of agile can cause a fail: https://www.youtube.com/watch?v=lAf3q13uUpE
I completely agree with Tom Anderson, that the circumstances are more important that the type of project itself. For example, if you have signed fixed contract (either because of your management, or a client), you probably have detailed requirements. If you have detailed requirements, you wont run scrum but "SCRUM BUT". It's against agile philosophy.
It may happen that the project is not suitable for neither agile, nor waterfall.
Sometimes it's better to use agile internally having Product Owner role assigned to somebody from your company, who understand the domain best.
Suitability and Unsuitability of Agile methods?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm looking for the "best" agile-friendly feature and defect tracking software. Currently, we are using fogbugz, but this is not terribly useful for teams following an agile methodology as far as I can tell. There are better tools for this, such as Greenhopper for JIRA. I've used JIRA before, but I'm wondering if there are any other tools that are better.
I'll relate my experience, hoping it will be helpful.
We started piloting Scrum using cards on a wall. We figured we would switch to a tool once we started doing it for real. We set up our defect tracker (Redmine) with User Story and Tasks, and have a way to create a burndown in each project. What we found, however, is that you don't really get the transparency of a physical information radiator. People walk by the card wall and can see the team progress. Very few will check the web site as often as they inspect the card wall. So currently, we do the card wall for the current Sprint and track the Sprint in Redmine, which gives us historical information.
As we scaled up to more teams than we have wall space for, we realized we're going to need a tool that can work like a card wall and be a 'real' agile tracker. So we looked at several tools, and our short list included Version One, Rally, and Mingle. Either of these products might be best for you, but ultimately we chose Mingle for various reasons.
The one thing I worry about is the loss of the card walls. It's hard to explain the transformative value that these public information radiators have had. The teams get lots of visibility from the Product Owners as well as management and other stakeholders. I worry that the visibility will be lost if we switch to using solely the tool. I may have to build dashboards that go up on wall-mounted monitors, acting as a high-tech version of the card walls. One thing we did do was procure some touchscreen whiteboards that will allow teams in standups to move virtual cards in a familiar way, using the tool's drag-and-drop card wall interface. I'm hoping this will allow us to retain the team communication and interaction benefits we've seen when gathered around a card wall.
Anyway, good luck with your quest!
We are using PivotalTracker (http://pivotaltracker.com) in our projects. It is a lightweight and easy to use tool. It works in the cloud, so creating an account and setting up a project is a matter of minutes. User story and bug entering is quite easy. The tool supports a standard workflow of tasks consisting of Not Started, Started, Finished, Delivered, Accepted and Rejected states.
I haven't tried fogbugz yet but I used JIRA, Greenhopper and VersionOne before PivotalTracker. The downside of all these tools against PivotalTracker is that using them brings you too much overhead. You have to setup and maintain them. You have to configure them. And because they are harder to use, they require more time for daily usage. I have seen that developers hesitate to use these tools because they create too much friction. IMO PivotalTracker is the best tool in this respect.
The downside of PivotalTracker is that it gives only a few configuration options. It doesn't allow you to customize workflows. It doesn't have much user authorization options. But in our case it suits very good to our needs.
This might be a non-answer to some extent, but I hope it will still be informative and add value.
I've been on multiple teams using various tools including physical boards and Greenhopper. Other agile teams in my department have used and evaluated various other options. If you are talking about finding the most efficient way to manage the team within a sprint (as opposed to release planning, backlog grooming, etc) I've come to the following conclusion:
Nothing is going to be a great fit unless you wrote the tool yourself or use a speadsheet. Yes, a spreadsheet. It's the most flexible option I've come across. We use a fancy one with burndown charts and such, but it works great.
Any tool you find now which may be a perfect fit will eventually end up not doing something you want. Here is an example from my own recent experience:
We were working to bring down the length of time it takes to report status during out daily scrum meeting. The challenge was that developers have a tendency to go into a detailed explanation of issues they've encountered while working on a task. We try to postpone those discussions until after the scrum meeting. It was hard to do until we started simply highlighting any items in the spreadsheet we need to discuss further. This let us move on with the meeting but not lose track of issues that need to be discussed. It was effortless to introduce this into our process precisely because we were using a flexible tool like a spreadsheet. The tool didn't stand in the way of improving our process.
As for defect tacking, most of the teams in my department use JIRA.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?
Team should decide whether a tool is to be used; but I think suggestion most commonly comes from the Scrum Master as (s)he is most likely to have experience using tools. Any team member can suggest tools of course.
Anyway, my feeling is that given Scrum philosophy, the whole team needs to agree on this in my opinion. Usually things start with "let's try this, see if it works", and is refined along the way, just like anything else in Scrum. It should not be top-down enforcement, same way as using Scrum methodology should be team decision, not handed down from top.
Great question. There is a lot of value to embracing the self organization of agile and allow the teams to choose their tools. However, there are usually constraints imposed by the business. For instance, the business may not be able to support/want each scrum team rolling its own scm solution. The more established the business, the more constraints and push back. Even established businesses can change. Don't be afraid to question a constraint if the team can justify the change.
Agile planning tools will follow these same rules. The business may have a full software life cycle management solution in place. This solution may or may not have an agile module. However the business may have reasons (regulated industries for example) to require that design inputs / outputs are documented in the life cycle management software solution they have. The business usually needs to balance keeping the teams happy / productive with staying in business.
I don't think there will be a black or white solution (unless you are one of the first devs at a start up). Agile teams will need to embrace the open communication. If the tools are impediments the business needs to know.
I'm going to make simple answer, because I actually think this is a simple question.
The WHOLE team is responsible of that.
Let me explain a little bit.
We first have to accept that every context is different, so this is not a biblical answer.
Let's say you start your project. I always love starting my projects/products with nothing.
NOTHING. Sometimes, just a task board, with todo, in process, done.
That's it. And I fill the todo column.
And that's all my point: I build my agile process incrementally and iteratively.
Why should I have to create a Burndown Chart? Because literacy tells me so?
Hell no, because, maybe, eventually, at some point, I might need to have some visibility for my planning.
Same with everything. And never forget, Agile tools serve as a support for the process.
So, you're a PO, and you're tired of the simple todo list, and fell the need to do a Backlog?
2 Solutions:
-- you're already in a highly mature team, you just have to tell everybody during stand up meeting that you're taking the lead on it. Eventually it'll need a retrospective to accept that.
-- you're migrating from a V, W or whatever product management model. Then, wait the retrospective and ask everybody and explain your pain. Give solution (here the backlog), and ask for a shot.
So, you're a scrum master, and you find a "systemic bug" in your process, let's take the classic one: Too many bugs. Then take the lead to promote TDD, or systematic testing.
So, you're tech lead and feel... Well, you understood me.
My point is: never over tool your process at the beginning. Build the process slowly, add tools slowly, when you need them. And by doing so, don't worry, people will take reponsability to create the tool and add it to the process, to lobby it to the rest of the team.
Hope this helps.
What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?
Well my experience from real life is that, certain "Agile Planning Tools" tools were handed to the Scrum Teams before they even started their Sprints, fortunately the Teams liked it, but we were free to inspect and adapt to using something else if it did not work out for us.
I think it should be in the Teams power to use, accept or reject a tool in a completely transparent way. They could very well take suggestions from the Scrum Master or an Agile Coach because (s)he may have more knowledge in the Agile Tools area. Secondly, the Team should be courageous enough to have a collective discussion and decide on using a tool based on the Agile Coach's suggestions, and see how it works for them, and adapt and adjust from using it if it does not work for them (productivity-wise)
The bigger question which you did not ask is, how do you manage the differing tool set chaos when the company scales into having multiple Scrum Teams who use their own Agile Planning tools?.
Well, I think realistically, in a scaling agile software company, a little bit of uniformity in tool usage across Scrum Teams can be beneficial and productive but that may be directed by the self organised enterprise project Team instead of each Team having their own tools. Off course there can be exceptions, where certain teams are working on completely different features and they need a totally different tool set, but the benefit of using common Agile tools will help scaling projects view their Teams progress without much of change in gear.
The above can be done by having a Technical, Infrastructure and Process Tools Story which not many companies use or create. This EPIC story can be the starting point for discussion of what Agile tools and other tools can be used, to have a little uniformity within the project. While deriving the EPIC story the whole project team could be involved around project kick off, if it is too big then 1 - 2 members can represent each of the Teams. The story could be broken down exactly like business user stories, and modified accordingly and calibrated, estimated and prioritized through out the project from an infrastructure and tools stand point. Let me know if you want me to go in more detail about this.
Ideally the scrum master, but they may inherit some legacy which needs some evolution.
If the organisation is new to Scrum, then an experienced Scrum Master should be able to advise the best tools for the maturity of the team.
Typically, if a team already has some tools, a scrum master can adapt what is already there, regardless of the organisational choice. Some of the best boards are on Excel Spreadsheets and work just as well as a purpose built system. Every technology creates 'constraint'. So, it is up to the scrum master to support the business in ensuring the tools are fit for purpose and delivering the value the team needs.
Typical mistake I experienced as a coach was decision made by managers or even senior management according some study done by 'specialist' or even external consultant. Those people are many times not aware about what, how and who will yse the tool. In this case I see dissapointed people once they should use chosen tool.
You have to consider who is going to use the tool for most of the day. Team members are better target community. Tool must support ScrumMaster role due to daily work she needs to done. Include experienced product owners into selection of the tool as tools have different support for planning that is necessary to be usable.
Consider your organization (complexity of products, projects, number of locations)
The responsibility (and authority) of choosing a planning tool should be with the team. Often the surrounding organization will have a stake in terms of licensing costs and consistency across teams. Depending on how autonomous your teams are it should be OK for them to chose their own tool, though.
Within the team, the product owner usually has the highest stake in the decision, since he will be the one who is going to use it the most for continuous refinement and prioritizing. The rest of the team often only interacts with the planning tool during refinement and planning sessions once or twice each sprint. So he is usually the one driving the decision-making, but should definitely involve the team.
If the chosen tool also includes a board that the team uses daily to track their work, they will want to have more of a say in the choice.
Is there a way of offering the flexibility of Excel/Access development that end users love while instilling centralised IT management so data and logic is secure, backed up, version controlled etc. The common options are to re-write in C#/ASP.Net/Java/Python/Your Choice, but that takes away control from the users. Is there a better way, and what do you do at your site?
There is a universal issue of users creating fantastically useful Excel/Access mini-apps that the IT department would like to bring under control. Users love the flexibility that Excel affords, especially on the fly changes, graphing and data import/export. In Access we have brilliant QBE. The downside is that after a short while there are legions of out of control spreadsheets/mdbs which are mission critical, with lots poorly understood business logic, and brittle code, they're a pain to support especially as staff move on.
This puts the IT dept in an awkward spot, they'd like to support these apps, but don't know enough about them. This is made more difficult as they are typically insecure with zero documentation.
Having been of both sides of the fence I would go after the root cause of the problem. Why do uses make their own little apps? Because it is too hard/expensive/time consuming/never turns out right when they go through the “proper” channels.
The other thing is they tend to know the business very well so whilst their coding might not be very good their knowledge of what needs doing is very good.
So what can we do to combat this problem? I personally think their should be a small team of people within IT whose job (or one of their jobs) is to develop these small applications. They should work very closely with the end users and not be locked in the ivory tower of IT.
In my current role I’m on the non-IT side of the fence, I have a few quite major applications that needed to be developed so I asked for an install of visual studio and some space on an SQL server. I had my request denied. So I just asked for SQL server space, again request denied (each request taking about a week to go through) So in the end I’m “stuck” in access.
Now these are very nice access apps with version control, comments in the (shock!) and all the other nice things but at the end of the day I was trying to do things the “right” way and ended up being forced down the access route. So when my apps try to get scaled up and I’m quoting a long time for a rewrite who is to blame?
Have you considered looking at SharePoint for department-level applications? Many professional developers will balk at the idea of using Sharepoint for "application development," but it truthfully can be a great way for "power users" to start putting their data and tools in a managed framework.
With SharePoint, you can manage the overall structure of the site and then set up users with elevated permissions within their respective departments. There are some great 3rd-party tools to help with keeping an eye on what's going on in your SharePoint site.
SharePoint is not a silver bullet by any means, but it is great for many multi-user applicatinos that need to keep up with a list of data.
(The following is not really related to my above answer, but your question really hit home and I thought I'd share my similar experiences and insights.)
Our company will be going through a similar process in the near future. I'm on the "end user" side of things and can sympathize with a lot of what Kevin Ross said. Sometimes Access and Excel are simply the best tools available for me to get the job done.
Here's an example: I was asked several years ago to come up with a system for creating Purchase Orders to a vendor in China for product for which there is a 3 month lead time. Our ERP software had a few features for procurement, but nothing that even came close to the complexity of the situation we were facing. Years later, after going through several iterations of the application in Excel (VLOOKUP was a lifesaver), Access ("So that is why people using relational databases. Awesome!), and back in Excel ("let's not make this so complicated"), I still find that these Micorosft Office apps are the best tools to get the job done.
What's the cost to not use these tools to get the job done?
Contract work to our ERP vendor to add a special feature for this ordering process: are you kidding me? We'd likely pay tens of thousands of dollars for an unflexible monolithic application with horrendous user experience...and we would still end up back in Excel.
Buy third party software designed for this exact process: I've seen an on-site demo of software that does exactly what I want for our procurement process. It starts at $100,000. There are probably other tools that we can get for a few thousand dollars, but at that price point, I've already emulated most of their features in my own application.
Try to finish the job "by hand." : Ha! I'm a programmer at heart, which means I'm lazy. If it takes a solid week of sitting at a desk to work up a purchase order (it actually did take this long), you can bet I'm going to work up a solution so that it only takes me a few hours (and now it does). Perhaps the guy after me will go back to doing most of it by hand, but I'll use the tools in my toolbox to save myself time and stress.
It's so hard to find the perfect application to allow for maximum creativity on the user end but still allow IT to "manage" it. Once you think you've found a solution for one thing, you realize it doesn't do something else. Can I write I printable report in this solution like I used to do in Access? Can I write complicated Excel formulas that tie multiple data sources together from different sheets ("You want me to learn what? No, I've never heard of a "SQuirreL query" before. VLOOKUP is just fine thankyouvermuch)? Can I e-mail the results to the people in my department? Can it automatically pull data from our back-end database like I do in Excel and Access? Can I write my own code, VBA or otherwise, to make my job easier? The list goes on.
In the end, the best advice I can give to any IT manager in your situation is to respect the other workers at your company. Let them know their work is important (even if it's only useful to them and the guy at the next desk over). Let them know you are not trying to make their job harder. Don't assume they are morons for creating mission-critical applications in office productivity software; they are just trying to get the job done with the tools at hand and are usually quite capable and intelligent people. Invite them to explore different solutions with you instead of just removing the tools they currently have in their toolbox and then replacing them with ones they don't know how to use.
At the end of the day, if you have users who are smart enough to shoot themselves in the foot by creating complicated apps in Excel and Access, they are probably smart enough to learn to use the appropriate tools to accomplish the same tasks. Invest the time and energy to involve them in the process and you will have a solution that works for everyone at the end.
You could try a hybrid approach: Allow your users to use Excel/Access to home-brew their own, specialized tools, but take the mission-critical stuff and put it under IT control. There are a few strategies that could help you with this:
Make sure that your IT department is firm on VBA. Not the "yeah-everybody-can-write-a-few-lines-of-basic" type of knowledge, but in-depth training, just like you would if it were a less simple programming language. Although "real programmers" will tell you otherwise, it is possible to write large, stable applications in VBA.
If you currently have the data in Access databases, move away from that and migrate it to an SQL Server. This allows you to do centralized backup and management, while still giving your power users the flexibility to "link" these SQL Server tables to their Access frontend.
Commonly used business logic should be under control of your IT department. This can be done either with VBA, by creating an Access library that is linked by your users, or in any of the .net languages, using COM interop. The latter sounds more complicated than it is, and it will increase the satisfaction of your IT department, since developing in .net is just much more rewarding than VBA (version control possible, etc.).
I would second one of Kevin Ross's main points:
I personally think their should be a
small team of people within IT whose
job (or one of their jobs) is to
develop these small applications. They
should work very closely with the end
users and not be locked in the ivory
tower of IT.
I think any IT department that has a lot of users using Access/Excel should have at least one properly trained and experienced specialist in developing apps on those platforms. That person would be the go-between to make sure that:
IT's priorities and policies get properly implemented in the home-grown apps.
the end users get expert help in converting their home-grown efforts into something more stable and well-designed.
I would second Tony's point that whoever works with the end users in revising these apps to meet IT standards should work side-by-side with the users. The Access/Excel specialist should be an advocate for the end users, but also for the IT policies that have to be followed.
I also think that an IT department could have a specialist or two on staff, but should also have a full-time professional Access and/or Excel developer as a consultant, since the on-staff people could probably handle day-to-day issues and management of the apps, while the professional consultant could be called in for planning and architecture and for the implementation of more complex feature sets.
But all of that would depend on the size of the organization and the number of apps involved. I don't know that it would be desirable to have someone on salary who is nothing but an Access/Excel specialist, precisely because of the problem you get with all salaried employees compared to consultants -- the employees don't see as wide a variety of situations as an active consultant with the same specialization is likely to see and thus the consultant is going to have broader experience.
Of course, I recognize that many companies do not like to outsource anything, or not something that important. I think that's unwise, but then again, I'm the person that gets hired by the people who decide to do it!
If it's mission critical, and it's in Access or Excel, is built poorly, and no one understands it, it is probably time to rebuild it properly.
When the 'users' are in control it usual means one particular person is in control of the architecture, design, coding and documentation... except they normally omit the documentation step. Source control and bug reporting, the touchstone of software development, is usually absent. Few instances of code reuse, due to the nature of Office apps (code modules usually embedded into documents) and VBA (little OOP, most VBA coders don't use Implements, etc). All this means that the resulting applications are not subject to get proper scrutiny and quality can suffer, meaning there are likely to be maintenace issues, escpecially when that one user leaves. I know because I used to be that person ;)
So in order to satisfy the IT department, the proper process needs to be applied. That one 'power' user can continue to own the design and coding but will get peer review, perhaps the serivces of a technical author and a dedicated tester, be required to use source control, perhaps consider integrating with enterprise systems, etc.
There is no getting around the use of Excel/Access. It's what's available, and still very powerful and flexible. The best thing to do is offer some guidelines as to how files should look and be set up. If everyone is using similar standards then the files will live longer and more productive lives, beyond the creator's tenure at the company.
You've got some excellent answers regarding dealing with the folks and the business side of things. So my response will be more technical.
If you are going to redesign the app have the developers work in the same offices as the users. Given the users updates every day or two. If the users have any minor suggestions give those to the users within a day or two. Ultra Frequent Application Deployment
Give the power users an Access MDB/ACCDB linked to the tables with a bunch of starter queries. Let them create the queries they need to export the data to Excel for their own purposes and distribution to clients.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
To those of you who started using scrum in your development teams: Did you maintain the traditional teams or form new ones? At our organization we are split into database, product development and frontend developers (simplified!).
I am interested in whether others actually reorganized their whole team structure due to scrum or if you formed dedicated project (?) teams combining e.g. one person of each "old" team.
I actually can't even imagine how scrum could work if you maintain your role silos. In scrum we build vertical slices through the product so that every feature delivered during a sprint requires all the skills you mentioned (plus QA which you did not). How would you create continuous collaboration and have people commit to the sprint if they weren't all on the same team? Seems like the most likely way to end in "Scrumfall" to me. I'm not an expert by any means but it seems to me that the sure way to fail at scrum is to think of it as a project management solution instead of an entire organizational change. Its cultural at the core.
To answer you question about "generalists". The easy answer is that by having certain people only able to work on certain things you create big fatty bottlenecks in getting to Done. With specialties you are always constrained at each step by having limited resources to work on something. In sprint 1 you may have a lot of db work to do where there is more than just that one dba can do. But then in sprint 5 where there is no change to the datamodel at all, your dba will be sitting around keeping bored. It becomes almost impossible in sprint planning to commit in a reasonable time if you have to divy up and assign at the task level by role instead of just grabbing the next set of priority features that fits your team's velocity. The generalist model will inevitably bring business value in the long run. You may just not see it right away until you achieve cross-pollination.
I would warn that if you are already in silo-ed groups by role, then you have to be very careful in am agile reorganization. Many people are not ready and don't want to be ready to lose their special titles and just become team members. I would think you should almost always expect some amount of turnover.
It is preferred that in scrum/agile development that most individuals on the team are 'generalist' meaning that anyone can reasonably step into any role so that anyone can pull off items in the backlog as the come and nobody is waiting around for others.
now this may not be the case in your situation today but doing things such as peer programming and standup meetings to see where people are having impedements and to improve cross pollination of knowledge will help in obtaining this goal.
At my company we create a temporary cross function team for each project. Our existing teams are still there, but it is really important that we have cross functional teams for scrum.
We generally try to mix up a little bit to get some cross-team knowledge, but we for the most part work on our specialties. But as the project progresses we can more easily help out on different teams
When I worked for my previous employer, the company reorg'ed the whole dev organization and product management. They put engineers, qa, and analysts in each team. The split was mostly vertical/functional with some exceptions. Those exceptions were a mistake - the architecture vertical did not fit, because it was really horizontal. I thought that cross-functional teams worked well. In your case, the db and front-end departments need to merge with the rest if possible, and new verticals specific to your product may be created
We split our team into New Product Development and Existing Product Maintenance, with the ability for any developer to hop from one to the other between sprints.
I think we have maintained the traditional team, at least for now. There are a couple of other teams within the applications branch of the Information Systems department where I work though these were put in just before we got into Scrum.
There is a big project most of us are on that is using Scrum and the team seems to be evolving along nicely. We have some new tools and processes that seem to have helped us a lot and given us a sense of "awesomeness" that hopefully we will pass on to the other teams.
For changes to a database, any of us developers can make the change in the development environment and then pass along the script to a DBA to be done when it is ready for production. For changes to the network, there are infrastructure folks that handle that and initially setting up a server in terms of O/S, network, memory, hard drives, etc.