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 attempting to adopt agile concepts and I have done a fair amount of research, but I have not come across the answer to one question. I know that while the developers are initially coding the tasks of an iteration, the testers can be preparing their test plans and test cases, but when testing begins, if there are no bugs being identified for further coding and re-testing, what should the developers be working on at that point? In my current waterfall SDLC, the developers would begin working on the next release's content, but with agile it seems that work can only be done on the current iteration/sprint until it is fully completed.
#user3329073 - so, out of curiosity, are you currently planning sprints and releases - or are you still using waterfall? Or a hybrid approach?
In any case, it would appear that during a planning cycle, your developers complete all the tasks they are meant to work on and hand those off to your QA team to test. Depending on the volume of defects or changes, they might either be fixing those defects or coding the changes - OR - are waiting for new work to be assigned to them. This seems somewhat odd - but it is perhaps due to my not understanding your situation fully.
Normally, I would expect that (especially in an Agile environment), the developers could be doing one or more of the following -
They could be writing test automation scripts, so that each new feature is covered by your test automation suite. (Are you currently doing test automation?)
They could pick up the next task/ user story/ requirement within the same sprint - and start working on that.
They could pick up some engineering task - such as code re-factoring for performance or other usual reasons, as well as other important (but usually not urgent) tasks - such as even documentation.
It all depends on the overall context in which your team operates. What are the organization goals for code quality, stability, performance, documentation? What is the test automation strategy? What are the tools available to enable developers and testers do their work fully?
In our engineering organization, for example, where we follow more of a Kanban approach for being Agile, we have almost no testers. We do Test Driven Development where developers must write test cases before they even start coding. Once the finish coding, they must automate the test cases they wrote, and test the code to ensure that it works. Once done, we do code reviews by our lead architect - and other engineering leads as needed. In the mean time, the developer goes on to the next user story or defect available to work on. Shown below is our Dev lane in our overall product development board.
Additionally, we have a separate lane for tracking important Engineering tasks and work that needs to be done - and if the developer has time on their hands, they will pull work from that lane - and work on it till completed.
We do have a 1-2 manual QA folks, who - along with Product Management - do an overall review of a specific set of features that are identified for being shipped in the next release.
So, like I said, it depends on what your overall approach is to managing your teams and to product deployment and delivery. The advantage of Kanban in helping you become Agile is that it helps you start where you are and improve your processes from there.
Here is some additional reading about our practices that might help -
All in the Day of a Kanban developer - http://bit.ly/1h7kBcH
Benefits of Kanban - 300% Reduction in Cycle Time - http://bit.ly/1bmuYLy
Hope this helps!
It does sound that during your transition to agile you haven't yet achieved full integration of your team members. Think about getting daily builds out to a test environment (or continuous deployments if you can) so that the testers can be reviewing work as it is progressing.
Additionally, as #Mahesh Singh mentioned, developers can be helping with the testing as well and will likely be communicating with the test team to guide them through the testing as new builds are going out for review.
No matter how you set it up, there is always a point in the sprint when no more stories are left in the sprint to start on, and the team needs to close out the iteration. This is where you want to have your 'cross-functional' team members so that they can help with whatever might be left:
Preparing demo scripts
Building installation packages
Documentation
Training preparation
Automated testing
Reviewing upcoming stories for the next iteration
Helping refine estimates
Playing some ping-pong!!
Related
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 6 years ago.
Improve this question
Firstly, I'm aware there is a UX stackexchange, but I'm a UX designer trying to get more of a dev's perspective! How can the UX design activity work well with a team of developers and testers trying to work in an Agile way? There seems to be reluctance to do any (UX) design up front, and to only engage users after something has been built, rather than prototyping and testing with users before making production-quality code.
The basic theory behind agile is that there should be close collaboration between the development team and the customer throughout the development cycle, and that the team has all of the skills needed to succeed.
In your case, the UX designer skillset should be represented on the team, and conversations with the customer about UX concerns should take place alongside conversations about functionality.
So, the explicit answer to "How can the UX design activity work well with a team of developers and testers trying to work in an Agile way?" is "In an agile way, of course!" You need to work on the same stories as the developers. Don't try to create a UX design all at once. Let it emerge over time as the stories are developed, just like the functionality. As the developers are working with the customer to understand the functionality of each story, you need to be present and discussing UX concepts. Functionality and UX should evolve together, so the developers always know both what the software should do and how it should look and feel to the user.
The developers have learned that big design up front is a bad thing; the same goes for UX.
A key aspect of Agile is responding to change over following a plan.
Creating a detailed UX design up front works brilliantly as long as the requirements are unchanging and there are no technical problems encountered that require changes to be made. Agile is all about handling these kinds of changes.
The best way for a UX designer to work in an Agile way is to think of it as a 'just in time' process. What is the best way for you to produce good designs but to do the work at the latest possible time that is practical?
In this way if a change does occur (for example there is change in priorities and you have to quickly focus on other work) then you are best positioned to quickly adapt.
As you can probably tell this isn't a one-size-fits-all solution. Each team needs to explore how they fit design and developement together. With some teams they might have the designer pairing with the developer and work on the design and development at the same time. Other teams might do their designs a few weeks ahead and run them by the users so that they are approved and ready by the time development starts. There are no hard and fast rules here, it is about doing that which the team finds to be most effective.
It is all about discovering the best compromise between doing detailed up front preparation and being able to respond to late changes.
You should try faster methods, as paper wireframing or balsamiq mockups which gives you a very good idea of what the system will look like, so you can test with real users and you are able to make an 'on time' delivery between sprints.
It is very important to discover what the user needs,or to be more accurate to see if they get the idea of your development before It's built.
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.
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.