Re: [scrumdevelopment] Re: Size of team a barrier to SCRUM and Agile
- Mike I have few suggestions.Scrum doesn't ask or prescribes a very detailed requirement document. There should be sufficient knowledge within the team to start the work. The backlog creation and adding the just sufficient details in the PBI's is the job of Product Owner; PO can create a rough draft and then team can comment on it. Any doubts/queries will be redirected back to customers. A scrummaster or agile PM should ensure this interactions should happen between PO, feature team & end customers. Scrum is all about agility and discussion so please dont prevent this flow. I used to be in the same boat, creating everything for the team but it didnt help the ultimate goal of self organizing team; now i have stepped back & team is doing a great job.I agree stopping a task in between and jumping to new is very bad & such multitasking should be avoided. If there are couple of projects tasks from all projects can be added to sprint. They just have to be prioritized. We know the teams velocity and any task more than the velocity wouldnt be done. if the team is handling 5 projects then there may be a case that the sprint will be full with the tasks of first two projects. If the tasks of other projects are to be done then we need more resources or team will have to drop task from project 1 or 2 from the sprint :) ( before or during sprint planning & not during the actual execution of the sprint).RegardsAbhilash
From: JackM <jack@...>
Sent: Saturday, 21 January 2012 4:53 AM
Subject: [scrumdevelopment] Re: Size of team a barrier to SCRUM and Agile
What many managers don't understand is that one of the most wasteful things is multi-tasking. In lean thinking they call this a transportation cost or a switching cost. Every time the developer drops what he or she is doing and picks up on something new, he has to relearn what he did and takes time to pick up where he left off. It's not a very efficient way to work. All of the experts will agree on this.
Now it's not always possible in companies to have dedicated focused teams, I understand that. Never the less Scrum Masters should strive to get to this point. There are charts in Mary Popendiecks book that indicated the effects of multi-tasking as well as sheduling teams to capacity.
Now how to deliver this message to your manager is a different story. Perhaps get him to read Mary Poppendiek's book on Lean and in particular the 7 wastes in software development.
Hope this helps
--- In email@example.com, Mike Frymyer <mfrymyer@...> wrote:
>dedicated teams to a specific work effort. This is due in large part
> I am a project manager and I work for an IT department that has 5
> developers. Those 5 developers are working on 4 - 5 projects at any given
> time. They are also responsible for support and maintenance.
> My CIO is very frustrated with the fact that they are unable to provide goo
> levels of efforts for their work. This leads to late deliverables. He is
> also pushing us very hard toward Agile methods thinking that will fix all
> of our problems.
> A typical development timeframe for the vast majority of our products is
> between 40 and 400 hours. This is for .NET and Business Objects reporting.
> I have taken the SCRUMMaster classes and from all that I see you need to
> that a developer needs to be present at all times; such as during the User------------------------------------
> Story definition and then decomposing the User Stories into more
> detailed requirements during the development or SPRINT.
> I have been trying to capture the detailed requirements for the backlog to
> eliminate the need tp have a developer spend time with the customer, but my
> boss says I am taking too long on the requirements (usually about 30 hours
> in as coompressed a time span as schedules will allow).
> I am looking for suggestions on what I may be doing wrong and how I might
> be able to utilize Agile without a dedicated development team to each
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
Why on earth is this so difficult for people to comprehend?Because it is much easier to *not* prioritize projects and features based on value, and still justify to their bosses that they are doing the right thing.Because it is much easier to say that the resources ( Yes, I don't like being called a resource ) are 100% utilized (or almost near 100%) than to look into cycle times, ROI and other factors to justify only working on one project at a time.
RamOn Thu, Jan 26, 2012 at 10:16 AM, woynam <woyna@...> wrote:
Even if you *could* multitask without any overhead cost, it would *still* wind up costing the business in lost value.
Ron and several others have posted examples *numerous* times that demonstrate that implementing multiple projects in parallel *guarantees* that all but one project will be delivered later than if the projects had been addressed serially.
A project delivered later is *lost value*. Are businesses aware of this? If not, why? You need to have a conversation with the business that clearly explains that they can have Project A in 2 weeks, or they can have it in 12 weeks. In possible world can they have 6 projects in 2 weeks, but we can certainly give them 6 projects in 12 weeks, with the corresponding loss in value.
Why on earth is this so difficult for people to comprehend?
Mark> project at the same time. If it's unavoidable, *be brutally honest with
--- In firstname.lastname@example.org, Seyit Caglar Abbasoglu <scabbasoglu@...> wrote:
> Some interesting stuff about multi-tasking
> It seems Human can not multi-task complex jobs. She can only context
> switch, and it's really costly.
> The last statement is pretty effective :
> " Whenever possible, avoid interruptions and avoid working on more than one> under multi-tasking conditions.* It's probably less than you think."
> yourself-- and your stakeholders-- about how much you can actually get done
> Perhaps your CIO should know about this.
- Go ask in the PMI mailing list. You will get a better answer. This is a Scrum mailing list.On Fri, Jan 27, 2012 at 6:00 AM, <devesh.kumar@...> wrote:
I am looking for Webinars for which I can claim PDU for PMI-ACP.
Let me know if you such webinars.
You can join the agile community of practice, and look under webinar, we have a few ones there
RamOn Feb 1, 2012 7:46 PM, "Joshua Partogi" <joshua.java@...> wrote:
Go ask in the PMI mailing list. You will get a better answer. This is a Scrum mailing list.On Fri, Jan 27, 2012 at 6:00 AM, <devesh.kumar@...> wrote:
I am looking for Webinars for which I can claim PDU for PMI-ACP.
Let me know if you such webinars.
- Hi Ram,I've used the 'Batman' (we ironically called it 'Developer of the week') approach. It worked well in a situation where there was a limited influx of emergencies.For a situation where there were a lot of emergencies (meaning the quality level was quite low) we put together a separate team that focused only on fixing those issues, and doing structural improvements to bring the quality level up.'maintenance' can mean fixing defects, but to some it can also mean implementing new functionality. If there's a lot of new functionality necessary for the existing, deployed application, then even with limited defects you can still get to a situation where there's no time to work on the new product. That's OK. But as Scrum Master, in that situation it helps to make things very visible. Present a little overview of what has been worked on for different projects at each Sprint Review, for instance. Preferably with a little historical data as well. Ensure that you measure actual velocity on the 'main project', and use that for any release planning. Transparency.WouterOn Thu, Jan 19, 2012 at 6:29 AM, Ram Srinivasan <vasan.ram@...> wrote:
Ron:Great Answer. Lot of us (including me) are in the same boat as Mike.Question.How do you manage new development, along with maintaining existing application/products, especially if the team is small, given that this team has actually developed the( now deployed) "cash cow" application. My answer is along the lines of have a batman (http://jamesshore.com/Agile-Book/iteration_planning.html ), but if there are multiple products to maintain (including hot fixes), it really becomes difficult. How do you handle such circumstances ?Thanks,RamOn Wed, Jan 18, 2012 at 2:28 PM, RonJeffries <ronjeffries@...> wrote:
Hello Mike,It is time for some tough love here ...How's that working for you? My guess: horribly. There's a reason:On Jan 13, 2012, at 10:26 AM, Mike Frymyer wrote:Suppose each project would require five weeks. Assuming perfect task switching, your delivery plans look like this:1234512345123451234512345SHIPBut you won't get perfect task switching. There will be overhead and mistakes. It looks more like this:184.108.40.206.220.127.116.11.18.104.22.168.22.214.171.124.126.96.36.199.188.8.131.52.5.SxHxIxPxIf you work on one thing at a time it would look like this:1111122222333334444455555xxxxxSHIP SHIP SHIP SHIP SHIPBULL. There are no late deliverables due to "inability to provide good levels of effort". There is only bad product management. The team should be assumed to be working as effectively as they can under the (let's face it, not very bright) conditions they've been put under. Once you learn to manage that flow, you can work to improve it. You do this by removing impediments, not by applying more pressure or adding in more work.The problem of MANAGEMENT is to select work in such a way as to get the best possible product by the desired delivery date. This will be a lot easier for everyone if the team only works on one thing at a time. Since it will also have lower overhead and produce fewer errors while delivering much sooner, it only has one downside: it will require some managers to make some decisions, which by the way is their job.OK ... How do you get these numbers? Are they estimated by the sales department? By the CIO? By you? By the developers?A developer present at all times? Do you perhaps mean a Product Owner? Tell me about your Product Owners, who must be business-side people, fully empowered to decide what goes into the product, and what does not. Did you notice in your ScrumMaster training that the Product Owner is solely responsible for the delivery of the best possible product by the deadline?You are a project manager. This is not a Scrum role as far as I am aware. Perhaps you are trying to take on the Product Owner role? If so, have you had Product Owner training?It also sounds to me as if no one in management is on board with doing Scrum, much less understands what it means. Am I getting the wrong impression here?If you are going to spread your teams over multiple projects, that is such a bad idea, that I implore you, as one of the authors of the Agile manifesto, to call your process anything else but not Agile.--
Wouter Lagerweij | wouter@...