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
I was researching on a popular agile method, Kanban but I couldn't really find any helpful material. Most importantly, I don't really get how WIP can be helpful in Kanban.
According to this wikipedia article, Kanban advocates limiting work in progress, which as well as reducing waste due to multitasking and context switching, exposes operational problems and stimulates collaboration to continuously improve the system.
This explanation about WIP came off as strange to me, because, I think, it's assuming that one worker is supposed to be working only on one of the whole Kanban stages, such as "to do", "development", "test", "finished" rather than take one item and take care of it over the whole stages. I think only two stages among them, which are "development" and "test", are the stages where you do work. So if you are working on "test" stage, is that the job you are supposed to do all day long without touching "development" process at all? It seems too rigid.. Is that really how agile companies out there work?
The quote from Wikipedia says:
...reducing waste due to multitasking and context switching
Note that it does not say 'eliminating waste due to multitasking and context switching'.
The WIP limit does not dictate one task at a time. The team tunes their WIP limit so that it provides the maximum throughput of work.
A team might try one task at a time per team member and realise that is not an efficient use of time. They could then raise the WIP limits until they found the sweet spot where throughput was maximised.
You're interpretation how kanban systems work and a WIP limits role in managing behaviour is incorrect, which isn't unexpected given the limited information available in the wikipedia article.
WIP limits are explicit policies that teams use to encourage the continuous flow of work through a kanban system. WIP limits are used to optimize pull behaviour given the needed operational characteristics of the kanban system (how does it need to perform).
This explanation about WIP came off as strange to me, because, I think, it's assuming that one worker is supposed to be working only on one of the whole Kanban stages
WIP Limits should not be implemented such that there is a WIP of 1 "thing" per person. That could happen, but it is unlikely given the scheduling needs of creative, knowledge work activities.
So if you are working on "test" stage, is that the job you are supposed to do all day long without touching "development" process at all?
WIP limits should manage work, not workers. A work item might be in testing, but that doesn't mean that a QA professional can't help somewhere else in the workflow. A WIP limit of 3 on Test means that only three work items should be in test at a time, and anything above or below that is not optimal behaviour for the system.
It seems too rigid.. Is that really how agile companies out there work?
Kanban is probably the most flexible of the methodologies that can support the emergence of agile capabilities in an organization or team. If you were to read Kanban by David Anderson or Kanban from the Inside you will get a much deeper and more accurate introduction to WIP limits and how they work in virtual kanban systems.
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
What happens in Scrum when the development team is the support team as well? How can this be improved using Jira?
We can't have a fire fighter because not all developers can solve both front-end and back-end issues.
But the support issues make team velocity difficult to obtain.
Mike Cohn wrote a good article on sprint planning for teams with a lot of interruptions.
He suggests having a rolling estimate of the average time spent on interruptions. Then allow for that when you do sprint planning.
For example, say the team averages 30% of their time spent on fixing issues. When you do the planning you plan for a capacity of 70% for development work.
As you mention in your question, nominating a person to handle issue fixes is a common approach. This is beneficial as it allows the other members of the team to focus on new development work without unexpected interruptions. In your situation where developers are specialists this is more difficult to achieve. You may want to consider doing some cross-skilling so that developers can handle a broader range of issues. They may not fix some issues as well as a specialist, but the loss in efficiency is gained back by the rest of the team avoiding interruptions.
Other things worth considering:
Triage bugs and only do the critical ones immediately. Schedule the other bug fixes as a part of your next sprint planning session. This may be easier to achieve if you have short sprints (say 1 week long) as the users will have less time to wait for a fix.
Analyse the bugs and see if some development work could potentially prevent future issues. For example, you may find that a lot of bugs occur due to bad data. Spending time making the code more tolerant to bad data can help.
Consider investing more time in automating your regression tests. This up-front investment of time can reduce the number of future bugs. It may seem like a lot of time and effort to do this, but making your workload more predictable can be valuable enough to offset this cost.
Production bugs have a bigger impact than the time spent fixing them due to the unpredictable way in which the work arises. That is why focusing on quality makes sense, even if it does seem like a lot of extra effort.
So the SCRUM is really for planned work, and if there is a lot of interruptions it may not be the best approach, maybe you should look at kanban or combination of both?
#Banarby Golden's answer very much answers the core question already, but since you've also asked about how to implement this in your JIRA project management:
I'd suggest using different projects or different epics for development and support tasks. Using a default Scrum project for development and a dedicated Kanban project for support issues seem's like a reasonable aproach to me (we are using this technique as well).
You can also create boards which span multiple projects, if you want to visualize the whole workload.
You could adapt the process based on the type of work coming in to sprints. It doesn't have to be set in stone as things can change over time.
Kanban gives teams just enough work so that they are consistently working at capacity.
Scrum divides work into sprints (fix-length iterations) allowing teams to work on top priority stories.
Scrumban is a hybrid of Kanban and Scrum. It's based on having a continuous flow of work and follows a pull-system. Stories exist in a backlog and teams still operate in sprints but WIP (Work in progress) is limited through each stage of the workflow and productivity measurements are in place using Cycle and Lead time metrics.
Note: Cycle time is the time a story takes from start to finish in the teams workflow. Lead Time is the total time the story appears on the Scrumban board.
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
I was reading about the necessary metrics for SCRUM and I couldn't find 'Defect Leakage' listed in there. This is the case even with the papers published by Jeff Sutherland.
I was wondering if there is any reason behind not considering this as an important metric in Agile SCRUM. Does anyone know?
Scrum is a minimal process improvement framework. It very deliberately doesn't talk about any metrics beyond meeting the sprint goal.
If your team find defect leakage a useful metric in helping them improve then they are, of course, allowed to use it. If the management outside of the Scrum team find defect leakage a useful metric - then they're perfectly free to use it too.
Scrum doesn't define the metrics you should use. It allows you to use any that you find effective.
There are no metrics in SCRUM. This doesn't mean you can't have metrics, it just means that SCRUM doesn't mandate them nor tells you what you should do in this case, hence why you aren't finding anything of the sort.
Since we're talking about SCRUM, one usual mindset to this is to ask ourselves:
is it useful? Does this <activity,metric,task> have a big value?
why do i want to do this? What will i get from it?
So instead of looking for the answer, i suggest you answer yourself that.
(PS: my boss asked me to is not the greatest motivational answer)
If you take a look at the Scrum Guide you can see that Remaining Work is only metric mandated as part of the Scrum Framework. As long as you can monitor Remaining Work you are at least looking at that one "thermostat" for your project.
Does that mean that you should not look at anything else? Heck no... as long as you continuously monitor your metric usage and watch for negative impacts on the team and organisation you can monitor whatever you like. Some teams require to do time-sheets for financing while other like to monitor mean-time-to-resolution or build quality. Although after looking up "defect leakage" I would question its usefulness.
p.s. Scrum is a noun and not an anachronism and so does not need capitalised
Scrum should not be set-up as an excuse for bad code or for defect leakage. If there is leakage, that means there will be items being added back into your backlog and unhappy clients. Most teams that I talk to using scrum also try to use techniques from xtreme programming, like test-driven development, junit tests, automated regression test scripts. No matter the tools, you should have QA resrouces booked 100% on the team, who are ultimately accountable for their processes around issue management and the quality of the deliverable that is deployed at the end of each sprint.
Another thought: if defect leakage is a metric expected by the enterprise, you could consider treating it as a criteria on a user story for sprint 0. But, if it's not important to the project or enterprise in general, you probably won't get it from the team during execution, or the team might implement it when problems arise in an adhoc, tactical manner.
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
Our team is debating whether we want to become Agile or not. None of us are really fluent in Agile. I'd like some thoughts on when Agile works well, and when it doesn't.
To give a little background, we are a small group of developers, six in total. We have far more work that we can handle. Our priorities change often. What is a high priority today, may not be tomorrow. We have many applications to create and maintain. We have started to dabble in Agile practices to the extent that we have daily scrums and two-week Sprint cycles.
If you need more information to answer this, please feel free to ask.
Thanks.
Ralph Stacey's complexity matrix is commonly used to illustrate the sweet spot for Agile:
(source: typepad.com)
For simple projects (where both the requirements and the technologies are well known), the predictability is high so a predictive methodology (waterfall) works well.
For complicated and complex projects (and the vast majority of IT projects are), predictability is low and a predictive methodology won't work, an adaptive approach should be preferred. This is where Agile works well.
When both the requirements and the technologies are unknown, you're close to the chaos and the odds of failure are very high, regardless of the methodology.
I'm speaking only from experience; YMMV.
My team was unsuccessful at making agile work. IMO, it was because:
The very first time the dev team
would hear about a project, it was in
the form of a requirements document
and a deadline.
Stakeholders were often reluctant
to take time to look at the result
of a sprint's work, thus they would not take action between sprints if they thought the project was headed in the wrong direction.
When we showed stakeholders our work,
they generally just OK'd it. They
would talk about what they would
like, to which we would reply "That
can be done in about X amount of
time," to which they would reply,
"Well no need to go over the deadline
for that."
The deployment process was long and
complicated, discouraging frequent
deployments. So in practice, we
often deployed things when a 2-month
project was done, not at the end of a
sprint.
Our sprint planning meetings were
long and inefficient.
It seems everyone was confused about what scrum is (and about what our process was), except for the scrum evangelists.
So I'm pretty sure we were doing it all wrong. Don't you do it wrong, too.
Some things that have sped us up, which we continue to use:
automated builds that work on
everyone's machine (HUGE help!)
a formal arrangement for our code
repository
learning how to apply apply
abstraction mechanisms to UI code
refactoring
unit and integration tests
continuous integration
I guess you could say that our code is more agile, though our methodology is less agile. Whereas before we could not keep pace with demands, now we can.
(I'm not saying agile is bad; I'm just reporting my experience. Also, please understand that I do not choose what methodology we use.)
Reposting a related answer of mine:
The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:
Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.
Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.
IMHO, Scrum would be useful, because:
Once every two weeks (or every month, depending on iteration time) you'll be able to see what's working or not. And this is very valuable, specially as an "amateur" team, which is expected to be learning and finding things out much more constantly.
As amateurs, you probably won't be able to foresee everything (and that's something agile embraces)
There's more space for sharing experience (stand-up meeting, retrospective, and even planning meeting). And you share REAL experience (you must write code every week rather than just plan)
It appears your priorities are changing far too frequently for either methodology Agile or Waterfall. With priorities changing frequently, you are likely churning in and out of projects leaving a lot of them partly done. The Agile alway be ready to release may help. It has been my experience that getting a methodology in place will improve productivity.
Your situation reminds me of a project I worked on. The developer on the project asked one question at the start, "Do you want me to be do it right or be responsive?" I was on the project when it was two years into a six month project. One week the same functionality was implemented Monday, Wednesday, and Friday. Tuesday and Thursday were spent removing the functionality.
I would suggest you start adopting practices from Agile. Scheduling a short sprint period could help with changing priorites. It may be easier to maintain priorities for a period of a week or two and may make it easier to stabilize priorities. You will also need a backlog (sounds like you have a large one already).
Management may be more willing to hold off new priorities if you can slot them into a sprint in a week or two. You will also be able to identify the priority tradeoffs. If you add something to the next sprint, what will be removed.
Consider having part of the team working Agile while the others maintain the status quo. Rotate one team member each sprint as you are gaining experience. Consider having the whole team participate in a daily stand up status meeting, and the post sprint review. Once you have demonstrated increased productivity and returns to the company you should be able to increase the amount of work being done using your methodology.
Agile is a adaptive methology. Expect to be making major changes to your methodoly for the new year or two. Eventually, you should reach a stage where you are fine tuning.
In my experience, you absolutely need the following for agile (XP or Scrum at least) to work. Without these prerequisites you are likely to fail. Hard.
Team must be stable and 100% dedicated to this.
Team must be colocated in one workspace.
Customer/product owner must be available on site at all times.
Support from management. This means providing funds and courage to ensure the points above.
Give these points, you can probably tackle anything as long as you keep to the values.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to figure out how to solve some challenges that my team is facing while attempting to apply agile. The one that is causing the biggest headache at the moment is due to the dual role nature of projects that come into the business.
Basically, we have a number of software that we produce and deploy for various markets. This software is planned and scoped in quarterly release cycles. At the same time we have large contracts come through that take anywhere from 1-3 months to complete. The problem comes from the fact that management wants to work on the incoming contracts first and foremost and all normally scheduled release work is brushed aside to get the next contract out the door.
We're trying to scope the releases to shorter than 3 months so that a contract would have to wait that long for work to begin.
Has anyone dealt with a scenario like this while trying to apply agile? What are some ideas/approaches to working on release scoped/planned work and keeping management happy that high priority contracts are being delivered in a timely manner?
The only way I can see is an internal market.
Assign a $ value to the next release of your 'real' product and then you can fairly apportion effort to that vs the incoming contract.
Of course the value of the 'real' product depends on management but at least it pushes the problem onto them in a rational way.
Instead of looking at your situation as multiple shorter projects that are interleaved into one longer project, you might instead think of it as a single larger project. The small projects then become interrupts or the equivalent of scope changes, which are things that all large projects need learn to manage anyway.
As with interrupts and scope changes, you will need to address schedule impacts, the effect of "context switching" overhead on your staff, etc -- and possibly consider dropping features or cutting back in other ways in order to make your next scheduled delivery date.
If management wants the new work to be done first, while the mainline project is put on hold, then it seems to me that's what you should give them. Why drag your feet for 30 or 45 days before starting the new project? From the perspective of a single larger project, that's certainly not very agile. You could instead get a faster start, and then communicate the resulting impact.
Over the long term, you may find certain staff members are slowed down more by periodic course changes than others. In those cases, you might consider making semi-permanent assignments, so they can continue what they were working on, even in the event of interrupts. Similar arrangements are typical in larger, interrupt-driven shops.
Even in an agile workplace there is some kind of "resource planning" at management level. As long as there is some predictability on when the contracts come in, the allocation of people to teams and between teams can be decided before the start of each iteration.
If an unexpected event occurs and it is necessary to terminate a sprint, or re-plan it mid-iteration then that's what you have to do.
Agile methodologies are supposed to help you to "embrace change" and make sure that the highest value requirements are delivered first. They don't change the fact that there is always more work to do than people to do it, but they do provide a framework for managing the chaos that this will cause if people aren't realistic about priorities, actual staffing levels and work rates (or "velocity").
Agile doesn't mean that there won't be difficult conversations, but if it's done well then the conversations should mostly happen in time to take some kind of corrective action.
I'm assuming that there is some kind of officially sanctioned agile process in place. I don't believe that agile methodologies (e.g. Scrum) can be made to work under the radar, because:
Agile methodologies are about self-managing teams. If your management doesn't accept the teams' right to self-manage then there is going to be a power struggle.
Agile methodologies are about having high quality communication both within a team and between the team and it's stakeholders. It doesn't work if the process is hidden from the stakeholders.
From the comments above, your process seems to be in pretty good shape. You have identified a genuine business problem and you are having a constructive dialog with your management team.
If you haven't got management buy-in, doing Agile is very difficult.
By the sounds of it, the management don't have a problem at the moment. They drop a contract on you, you do it, the quarterly release slips but they get the nice contract money.
Is your team large enough that you could conceivably split it into two teams: one focused on the internal releases, one focused on contract work or perhaps two teams that swap over responsibilities after each release so they each get to spend some time on green field and some time on BAU projects.
On a general Agile methodology note, you'd be better off with Kanban than Scrum because it sounds like if you tried to plan iterations, you'd end up with 90% of the work in the unexpected 'contract came in' column.
Who is driving the quarterly releases on your product: customer requests or what you would like to do? Like mgb said, what profit is the business making from them?
I think it's first important to define by what you mean to "apply agile." There are a lot of different parts of agile and I would try and start small with the pieces that you can do. For example, do you have a continuous build running? Have you developed a product backlog?
Working on multiple projects is difficult to begin with but without management buy-in (as Wysawyg mentioned), it will be difficult to become more agile. You need to show the benefits of agile development in terms of cost savings to management. Have you determined why you want to become agile? How will it help? Once you have shown why, then just start doing some of the pieces that you can and after you start seeing some improvements, talk to management about the bigger pieces.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm starting up a personal project to develop some open source software. I want to use Scrum as the PM process on this (as I like the Product Backlog, prioritisation, and if I can get them, the burndowns) but it seems to me that I won't get the full value because I can't at the outset guarantee the amount of time myself and my collaborators will be able to commit to work during a given sprint.
I know there are other benefits that I will still get from using Scrum but are there variations or tricks and techniques I am unaware of which will enable me to get the value of things like burndown charts and timeboxed iterations? Or am I just being too hopeful?
TIA.
Regs, Andrew
As this is a hobby project, are you actually concerned about deadlines? How much value would it in fact give you to know how much will be done after a Sprint?
If your answers are no, you might want to look at a kanban approach as an alternative.
I think about agility in software development and come back to three aspects which provide real utility:
A known backlog of tasks to do
A regular opportunity to openly discuss the current status of tasks being addressed and hurdles to overcome
Team-managed iterations that result in a working subset of the eventual full product
In a work environment, say my 9 to 5, it is easy enough to adopt such a methodology. You've got devs who will be there at least 40 hours a week, every week and so there are few barriers to engaging in an agile practice, like Scrum.
In "after hours" settings, commitment levels of participants often vary. That's life. So you work with what you've got. If Matt is excited about the project but his schedule is busy and the number of hours he can dedicate to the project will fluctuate a bit, so what? If he's "on board" and serious about the time he is willing to invest in the project, then it is just a manner of planning your iterations accordingly.
I personally wouldn't get wrapped around the axle about this, though. In the end, Scrum or any 'agile' process that you adopt should be a means to an end, not the end itself. Particularly in an environment where conditions will differ from those in the 9-5 world, you need to be flexible in your iteration plans. You still plan your work and work you plan and engage in the regular communication and the "where are we today?" exercise to keep everyone in the loop.
The goal is solid software - if you can't get a lot of utility out of a particular aspect of Scrum, or any process, so what? You'll likely develop a hybrid process anyhow. I wouldn't get too too concerned about getting things like burndown charts and velocity and all that. I honestly think the focus needs to be more on quality software being developed and less on the artifacts that might help down the road in the next iteration or the one after that. That's my opinion though.
My advice is to use the things that work and keep it simple. Backlogs are great and the daily 'meeting' to touch base with everyone - even if this is a virtual one done by IM - is where the real value is found. Hobby or side jobs are tough things to commit to and I wish you well with it. But be open to the fact that it might not work as well as the process would at the 9 to 5.
In a by the book setting you won't use real time for calculation of the burndown chart but rather story points. After a few sprint you will see an average velocity and thus be able to generate a burndown chart and use this velocity for commiting to the sprint items.
And I strongly disagree with warrens post on the scale-down point. The main problem I see is a strongly varying velocity between two sprints, since it is only a hobby.
When the amount of time the Team is able to put in at every iteration varies too much, the velocity cannot really help to plan the Sprints since it will vary too, especially at the beginning. However, the average velocity may start to stabilize after several Sprints.
Nevertheless the burndown charts will be useful still as they show an accurate status of the current iteration.
You'll also take advantage of the estimations "calibration" Agile processes bring.
The problem with Scrum for this sort of project is more around the type of development team structure that Scrum is designed to support, in particular the colocation of the team for the daily standup meetings. Its hard to have a daily standup meeting when you aren't at the same physical location. In addition, I doubt you will have a Product Owner on your team, and you will be both the Scrum Master and a developer. On top of this you and your other developers will be working at different times and days may go by without any work being done at all. This may make coordination of the team difficult.
Every project, regardless of develoment methodology, should have a good idea of what needs to be done (the product backlog), what needs to be done shortly (the sprint backlog), and how long it will take to do these tasks so you have a reasonable estimation of how long the project will take (the project velocity and burndown). It is the other parts of Scrum that you may have problems with - not being colocated for meetings, the lack of a Product Owner, using a notice board to show the sprint status, etc.
This is not to say you can't modify the Scrum process to suit your purposes. For example:
have video conferences/Skype calls/IM meetings at prescribed times several times a week even if nothing has been done. Daily is probably too often for this type of project but maybe three times per week would work for your team.
use a web based issue management system so you can all see the product backlog, know what the sprint backlog is, and know what people are working on
have set sprint lengths (say, 3-4 weeks) so that the developers can sense the momentum and know the deadlines
understand what time is being spent on development so you can work out your project velocity and what can be acheived in the next sprint. This may be hard as available time will vary from sprint to sprint.
have retrospectives after each sprint so you can tune your development process with respect to what went well and what didn't. This would be the ideal time to meet at the same physical location if possible.
Scrum, at its essence, is mostly about effective communication so if you get that right you should be able to make a modified version of it work for you. Just remember that communication reduces in effectiveness down the list of
In person
Video conference
Skype/phone/voice calls
Instant messenger
Email
so try to use the most effective method at your disposal for your meetings.