How to handle customer''s attempt to push out of scope items in the name of agile? And does being responsive to changing customer requirements mean taking on more work even if it either reduces the project''s profitability or is economically undesirable? Saving Changes...
Lawrence CooperCreator, Lean-Agile Strategy| AdaptiveOrg Inc.Kanata, Ontario, Canada
I am biased like Alistair and Silviu''s article link is a great reference. Agile is based on setting time-boxes for the sprints/iterations. And it relies on stable teams who can work at a sustainable pace. It is also premised on delivering the highest value things first. As a result, if the number of time-boxes that will be used are fixed, if you have a set team size that is assigned to do product development, the you can look at as also fixing the cost.
For example, using simple math, if we have 14-day sprints (i.e. two work weeks or 10 working days), a team of 6 people with an average burn rate of say $500/day, then each sprint has a cost of $30,000. If the client only has $120,000 available, then it becomes simple math to say that the team has 4 iterations in which to deliver.
The product owner, via the prioritized backlog, establishes for the team what they need to focus on in order of delivery. Each sprint review becomes the opportunity for the product and the business to re-prioritize the backlog for the next sprint or to add new work which has to be prioritized. If the number of time-boxes (in this vase 4) are unchanged, then the cost remains at $120,000. It is up to the product owner and the business to decide what they get for that investment – not the team and not the PM.
A charter or a product vision are great for getting started but agile is all about inspecting and adapting based on what you now know that you did not know previously. It isn’t just the architecture and design that is emergent, but also our understanding of the problem we are solving. Embracing emergent problem understanding is what helps us recognize the folly of trying to lock everything down up front. There is great phrase for it “I’ll know it when I see it” – which most product owners and business-types can relate to. Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
It is a customer''s right and responsibility to determine what is in scope. This really has nothing to do with agile, this is simply basic change management. Customer needs change and we need to align our efforts with these changes within whatever constraints might exist. Instead of trying to provide a simple yes/no answer, just present various alternatives to meet the new needs and let the customer determine an accepted approach. Saving Changes...
Hi Wayne I agree with you but the customer has to exercise rights within the budget constraints which are also defined by customer. Often we find customers who want changes and yet do not see the logic behind having to let go of some other feature so that the change can be achieved in the limited budget.
Also Lawrence what you say make absolute sense and in a perfect world it would be the best solution. However often the customer product owner is some mid management person nominated for the role as no one else in the customer organization wants to take additional responsibility. However the product owner is aware of criticism that might be directed towards him/her in case somebody''s expectations are not met and often this results in a stalemate as the product owner is unable to prioritize user stories in the product backlog and wants to push the vendor to deliver everything instead of sacrificing less important stories for more important ones. Saving Changes...
Lawrence CooperCreator, Lean-Agile Strategy| AdaptiveOrg Inc.Kanata, Ontario, Canada
The by definition they are not being adhering to Agile''s values and principles, and if they are following Scrum, they are also not following it properly. We don''t get the real value from agile if we aren''t prepared to make the shifts that are necessary. If we want to do what we''ve always done, we continue to get what we always got.
Learning something new sometimes means we have to unlearn the old ways of doing things. That will take time of course, but if it worth doing (assume it is otherwise we would not have started it) then it is also worth investing in doing it right which includes the time for retrospectives which help us uncover how we can improve in our application of the practices and techniques we are using.
We should not diverge from the agile because it is hard - it is hard so we need to put in the hard work. Saving Changes...
Howard LaiPMP, CEng, CPEng, NER, IntPE(Aust), RPEQ, MIET, CSSBB, CISA, ISO9001 LA| QHBrisbane, Queensland, Australia
Customer''s attempt of pushing out of scope items is a very common scenario. But using the name of Agile need common agreement of project approach before project started. Stakeholder engagement is a key factor to ensure both project team and customers are aiming at the same goal.
Being responsive to changing customer requirements may not mean taking more work, but change control need to be applied in order to maintain the defined scope. Saving Changes...
Lawrence CooperCreator, Lean-Agile Strategy| AdaptiveOrg Inc.Kanata, Ontario, Canada
Change control in Scrum is handled during Sprint Planning by the Product Owner - it isn''t the PM''s role to take on "defender of the scope" in Agile as it is was/is mistakenly done on traditional projects.
The customer via the Product Owner can add/change/remove or reprioritize items in the backlog during Spring Planning. To do this they do consult with the product development team to make sure it is logical from a sequence of delivery perspective when deciding what goes in the next Sprint - but neither the team, the PM or the ScrumMaster decide what''s in or out of a Sprint or the business priority for the backlog items.
It is also up to the Product Owner to decide when enough business value has been delivered and that no more Sprints will be needed. Likewise, they can also decide to add an additional Sprint in order to add more business value to the product (with the money to go with it of course). This is both the essence and the beauty of the agile approach - the PM is no longer required to be the task master they often become under traditional approaches.
Yes all of this is still done in the context of strategic goals/objectives/priorities but the teams have far more say on how things are done. Sprint reviews and product demos are where others get to see and have a say about what has been done so far. Realizing that the average sprint is two weeks for most agile team that''s a pretty short feedback cycle to make sure the right things are being done in the right way.
There is still a need for Portfolio, Programme, and Project leadership but with a distinctly agile focus to their roles, processes and artifacts. We can''t use the existing ones in their current form as they are not really geared towards agile thinking. The same is true for the tools we use on traditional projects as well.
We talk about this in Section 2 of our book on how models shape our thinking (https://leanpub.com/agilevaluedelivery-beyondthenumbers). We can no longer apply the same models and say we are somehow doing something in a different way. Agile is a different approach and you need to adopt different models of thinking. Saving Changes...
