One of the tenants of the Agile Manifesto is that we value “Individuals and interactions over processes and tools”. That doesn’t mean we don’t value process and tools, but rather that teams of highly motivated people, working together, and empowered to make decisions in order to get product out the door, can do amazing things. I have seen it many times in my career. We get better product, better people, better teams and better retention.
Almost paradoxically, I also really believe Kristof Kloeckner’s insight that:
“Agile without discipline won't scale. Discipline without Agile can't compete.”
Too many software product teams define agile as “whatever we end up delivering”. That’s doesn’t work and that’s where the discipline part helps. That’s also why I like Scrum. Done properly, Scrum adds enough discipline to make agile work. Sprints, backlog grooming, daily stand-ups, sprint demos, all add structure to the way we do agile.
It’s been my experience, both here at Vital Source and in my previous companies, that the roles of Product Manager and Engineering team in Scrum can have conflict, unless we have some understanding upfront of who owns what. The way we have chosen to explain ownership is by what questions each role answers:
Product Manager answers: “why” and “what”
Engineer Team answers: “how” and “when”
Even though we choose to define roles this way, hopefully this doesn’t mean that we don’t listen and get feedback and input when answering these questions. Here at Vital Source we have Product Managers who have a good understanding of technology, and Engineers who have a good understanding of the Products we deliver, which facilitates discussion and consensus.
To clarify the roles some more, the Product Manager owns the priority of the backlog, and the message of why things are in the backlog and why they are in that order. PMs spend time talking to sales, account managers, stake holders and customers in order to prune and manage the backlog. PMs spend a lot time in both outward and inward communications about the products they manage.
The engineering team is responsible for the execution of the backlog. By using estimating techniques, the engineering teams estimates how many sprints something will take and when coding and testing will be done in order to deliver a solid product. When considering implementation, the engineering team will make time for technical debt, and make decisions on tools, languages and software architectures.
If would not be appropriate for the engineering team to change the backlog order without sign off from the product manager, neither would it be appropriate for the product manger to commit to a delivery date or technology implementations with out sign off from the engineering team. When I personally see these things happen, I speak up. Hopefully others do as well.
That’s not to say we won’t make mistakes along the way. We are all at different stages of learning the process and coming up to speed on what we do. I hope we can be tolerant of mistakes and helpful when things go wrong.
If we can truly learn to value "Individuals and Interactions" and worked towards being a jelled team, we can deliver great product and have fun in the process.
