Dependency management is a key aspect in Scrum. Dependencies between Scrum team members, between User Stories, between core and extended team, between team and product owner – all have an impact on the efficiency and effectiveness of the team.
I often see Scrum teams having dependencies on User Experience/Web Developers. This is because PO has defined requirements for new sprint, and UI/Web-Developers who are part of development scrum team start working on this now. Wire-frames are yet to be created as per these requirements.
Developers get delayed in starting new stories:
• Due to lack of wire-frames and HTML
• Unapproved wire-frames
• Wire-frames undergoing changes frequently within the sprint
This breaks the flow of scrum team; creates lot of re-work and team fight to finish by end of sprint. This leads to sprint deliverable being low on quality and not tested by end of sprint.
You have to be careful about this pattern while coining new teams. I strongly feel team structures play a very important role in making Scrum a success in the organisations. Scrum teams have to bring this issue on the table and work a solution to reduce unwanted delays.
One way to solve this is by creating a Product Owner team with Product Owner, User Experience and Web Developers. This team runs their own sprints which are couple of sprints ahead of development sprint. They deliver prioritized user stories (detailed enough) as their sprint deliverables and all wire-frames approved with final touch. These deliverables would feed into Development team sprints.
Organizations have to come out of traditional thinking to evaluate different team structure which breathes Agility.
Have you come across similar situations? or Please do share other situations where you have made team changes quite different from traditional structure.
This is actually a very common occurrence and I see it most prevalently in organizations that have adopted Agile more recently. I think this is largely due to the misconception that because Agile is not Waterfall in nature therefore it relieves all dependencies. Just because you do not track dependencies does not mean they do not exist.
In fact Agile does not mean that there is *no* plan. Quite the contrary. It is just a minimalist plan such that change management is handled efficiently. I worked on a poorly planned Agile project and the amount of rework due to improperly prioritized user stories was incredible. 75% of it was exactly as the author stated here – they never planned to have web development/wireframe team in front of the development effort.
We also had user stories relating to roles/security but the architecture team did not have the role membership provider on their schedule until 6 months later. All security interactions had to be mocked but the PO was under the impression that it was completed since the functionality appeared to be there. What a surprise when the architecture team found out the requirements that the application had to fit into an existing custom security architecture. The entire security layer needed to be completely rewritten due to a simple dependency that could have been easily resolved with proper planning.
Michael,
Great Points. I agree with you. Teams were doing lot of dependency planning, rather I would say too extreme, going to the task level which was not needed when they were following waterfall. But now when they adopt Agile, organisations don’t do any such planning at all which is other extreme. Somehow they neglect this completely and then I have seen teams concluding that agile does not work for them.
We have a scrum team of the User Experience specialists and the Graphic Artists. This allows them to collaborate with each other (consistency and new ideas), as well as work with the product teams. Like our development tams, this scrum team is distributed (India, UK, Israel, US). It works its own product backlog, with deliverables dates that are ahead of the developers.
Thanks Betsy for sharing your thoughts. That’s great to know such a widely distributed team is working well for you. One interesting thing I noticed in your comment is, you are saying they have their own product backlog? Which is quite different than what I believe in of having one product backlog for one product.
As Betsy, explained that they have two different product backlog, one for team that working on grooming of Product Backlog along with designing of wireframe and other is for team that actually do the development. Here in my organization, instead of having two different product backlog, we divided our team in two parts, one is BA sprint team and Development Sprint team.
These two team have different sprint activities like BA sprint team works on grooming of Product backlog and preparing final requirement using Wireframe designing, updating of user story requirement in TFS, and this BA sprint team always working on user stories that will be developed in next or future sprint of the development team.
This way, we are overcoming the problem of dependency of User Experience/Wireframes that faced by Development team.
@Gurdarshan, Thanks for sharing your idea. This is great way of overcoming this problem. This would keep scrum team on sustainable pace always with very less rework or roadblocks due to this.
Very familiar with the destructive nature of ill defined wireframes. It is better to rewrite wireframes into supportable and understandable User Stories…