- Jean, It sounds to me that the team could use some quick wins. Those are usually to be had from properly splitting stories (using evolutionary designMessage 1 of 5 , Apr 1, 2013View SourceJean,
It sounds to me that the team could use some quick wins. Those are usually to be had from properly splitting stories (using evolutionary design thinking), working in short cycles (1-2 weeks), and effectively closing the feedback loop with the product owner. Quick wins are tangible examples of getting to done and they build teamwork and energy. Whether you break Scrum or not is less important, IMHO, than for the team to demonstrate to themselves that they can build working software by coming together.
However, quick wins lose their edge if the team has no incentive to get to done. That happens when there's no prospect for releasing that done code anytime soon. If your team is working within a framework that deploys to production every few months, you may well need to have a meeting with the entire Agile team to help them see the value of getting-to-done despite lengthy product cycles. A simulation might help.
All the best,
Author, "The Human Side of Agile: How to Help Your Team Deliver"
- Hi Jean, Always a difficult situation. You see so many improvement opportunities, but they also take time and effort to learn by the team. I would be hesitantMessage 2 of 5 , Apr 1, 2013View SourceHi Jean,Always a difficult situation. You see so many improvement opportunities, but they also take time and effort to learn by the team.I would be hesitant re-defining the definition of done for stories that have been taken into the sprint. The DoD should be current state, and not aspirational. At the very least, also include the definition of ready, stating explicitly what you expect of stories to be taken into a sprint.In this situation I'd probably (every team is different...) try to negotiate the PO to deliver (much) less this sprint, using the old criteria of 'done', and spend extra time with him and the team to groom for the next one. Use that to teach about functional splitting of stories, acceptance criteria/examples, etc. And to show the PO the amount of work currently ending up in the team. Take those stories into the next sprint, but not too many. Then start delivering.WouterOn Mon, Apr 1, 2013 at 5:56 AM, Jean Richardson <jean@...> wrote:
Two weeks ago I stepped into a Team during the their Planning Day and over the next few days helped the Developer/Scrum Master, who had been none-too-gleefully inhabiting two roles for several months, transition back into a full time Team member role. I’ll be spending a few sprints helping this Team step up their practices while the company looks for a Scrum Master to backfill. Then I’ll move on to another Team in the org.
This org has a pretty rough reputation and a high turnover rate. Quite a bit is broken, including the way the backlog is built stories are written, groomed, and tasked, and commitments are made. At this point, I’m looking for a way to salvage the sprint, boost the Team’s morale, and not break Scrum. The current state of things is such that rapidly improving across the board is the best goal. Okay, maybe not completely everything at once, but you get my drift.
The org is aligned such that reasonably renegotiating what is in the sprint is not synonymous with failure. And, on Planning Day, I did the step-in-front-of-a-speeding-train move of pointing out the Team’s right to not accept stories that are not ready to bring into the sprint, which drastically cut the commitment they were poised to make. However, what has become clear in the last couple of weeks is that the Team is at sea about what it needs to know to actually do work on a story.
As of last Thursday, it became clear that, while we can measure our newly minted Done Criteria against the state of the stories to determine how close to done we actually are, the original stories are not necessarily in line with the work that needed to be done. So, for instance, one story was structured such that it really focused on doing a requirements doc and getting signoff from the business. Now the Team understands that the entire cycle happens within a given sprint and the only person they need signoff from is the Product Owner.
Tomorrow we’ll be actively engaging with the Product Owner WRT how to renegotiate to salvage the sprint. What I’m struggling with is where the line is in the muddle between maintaining appropriate quality controls and integrity and fostering the success that is possible. At the most extreme, this could come down to re-casting stories and tasks at this point.
Keep in mind that this work group has had a practice of backwards engineering story points based on actual hours at the end of the sprint, assuming stories span sprints, and doing most of the testing outside the sprint in an IV&V fashion—among other things.
Thoughts? This Team seems poised for failure again, but they’ve been learning and applying things like real troopers for the last week and a half. It seems regrettable that the sprint should be a total failure, AND learning is necessary.
Azure Gate Consulting
~ Repatterning the Human Experience of Work
Wouter Lagerweij | wouter@...