54020Re: [scrumdevelopment] Size of team a barrier to SCRUM and Agile
- Jan 18, 2012Ron: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:220.127.116.11.18.104.22.168.22.214.171.124.126.96.36.199.188.8.131.52.184.108.40.206.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.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.
- << Previous post in topic Next post in topic >>