Within agile development, Scrum has the most to say about exactly what is agile project management. So let’s use Scrum as our model for answering this question. On a Scrum project, there are three roles: product owner, ScrumMaster and team.
The product owner is responsible for the business aspects of the project, including ensuring the right product is being built, and in the right order. A good product owner can balance competing priorities, is available to the team, and is empowered to make decisions about the product.
The ScrumMaster serves as the team’s coach, helping team members work together in the most effective manner possible. A good ScrumMaster views the role as one of providing a service to the team, removing impediments to progress, facilitating meetings and discussions, and performing typical project management duties such as tracking progress and issues.
The team itself assumes agile project management roles when determining how to best achieve the product goals (as established by the product owner). Team members will collaboratively decide which person should work on which tasks, which technical practices are necessary to achieve stated quality goals, and so on.
So, what is “agile” about this process? Agile project management divides responsibility among more than one team member. In the case of Scrum, it’s a project’s product owner, ScrumMaster and the rest of the team.
Customer Value + Agile + Data Driven
- They develop a holistic view of market segments, customer needs, and value proposition – Sounds like a 101, but many product owners dive right into developing solutions without developing segments, personas, and values as a guide.
- They are great listeners and collaborators – The best product owners know they are sitting in the center of a virtual circle between sales, marketing, technology and other stakeholders that have different opinions and skills. The best product owners listen first and collaborate with the team on priorities and solutions.
- Leverage agile strategically to shape their product to market need – They capture customer feedback and use it to reshape their vision, requirements and priorities. They pivot when required and experiment to see what’s working.
- Sell their vision, detail their stories – Great product owners have to be excellent communicators to get larger teams to understand and follow their vision. They also have to be strong practitioners, best demonstrated by making sure the active agile stories are precise on what is required.
- Leverage a network of key customers and prospects – Great product owners develop these networks to get insight into the industry, test ideas, pilot new capabilities, or capture critical performance feedback.
- Partner with technologists on platforms, standards, and prototypes – Every organization develops standards to be efficient and leverage skills and investments. The best product owners learn to leverage these to their advantage by reapplying existing capabilities to accelerate speed to market rather than developing new solutions from the ground up. And when new capabilities are needed, they partner with technologists to develop prototypes to validate and gain consensus on approach.
- Review financial performance and contracts – Great product owners understand the fundamental financial performance of their products, profitability of key customers, health of the sales pipeline and other performance metrics. They also review customer contracts in order to make sure their requirements can be met.
- Develop KPIs and use them to drive priorities – Product Owners need to insure their teams are data driven in their decision making. Their role is to define key KPIs on the products performance in areas such as financial, customer satisfaction, risk and other criteria to help drive priorities.
- Develop brands, platforms, and ecosystems – Winning at digital business requires product owners to recognize that products do not survive in silos. They need to consider how their offering might evolve to become a platform or interface into appropriate ecosystems. They must also partner with marketing to build brand, attract prospects, and develop relationships.
- They balance priorities to short and long term needs – Product owners have the tough job of digesting all the issues, wants, and needs demanded by top customers and sales people, the technical debt and other system priorities escalated by their technologists, branding and messaging ideas escalated by their marketing professionals into a manageable prioritized list. Then comes the harder part of determining how to best balance these needs against the strategic vision and long term success drivers.
And here’s an extra one – one that many product owners under the stress of market conditions, difficult customers, challenging stakeholders, engineering realities often forget –
- They celebrate small wins and thank the team – Things go wrong all the time and the team is never truly ‘done’ with everything that customers need and product owners want to deliver. Great product owners know how and when to thank the team and individuals on accomplishments both big and small.
– See more at: http://blogs.starcio.com/2016/04/10-practices-strong-agile-product-owners.html#sthash.roKOc6H5.dpuf
4+ Reasons Agile Game Dev is Tricky
Number one: the insane business model based on packaged games. Develop a game for years, market the hell out of it, ship it, profit, repeat. Crunching hard is probably in there, as is going bankrupt. Each year fewer and fewer games garner a larger share of the sales, and budgets are often reaching into the hundreds of millions of dollars to continue this model. This is pure insanity, so development methodologies of greater sanity, like those based on Agile principles, simply cannot thrive. Often they struggle to even take hold. Don’t underestimate the depth of this problem. We have a generation of executives and marketers (and developers) who know only this model, and trying to explain to them how you need to be flexible and iterative with releases and develop with tests can feel like a losing battle.
Number two: We’ve equated Scrum with Agile. Agile embodies a set of principles, but we’ve equated those principles with a (limited) set of tools: the Scrum project management methodology (you can substitute Lean and Six Sigma in the previous example; this phenomenon is not unique to games). If you’re ever tried to impose Scrum on an art team, you can see how much of a disaster it is. Rather than take Agile or Lean principles and ask “what is a good way to work that values these principles?”, we just institute some form of Scrum. I’ve seen many people dismiss Agile because Scrum failed, which is a shame. And like Scrum, I’ve also seen forms of soulless Kanban implemented (soulless because it doesn’t support the principles of Kanban, like limiting work and progress, managing flow, and understanding constraints).
Number three: Game development was late to the Agile party. Software has had about 15 years to figure out how to apply Agile to business and consumer applications and websites. While “flaccid Scrum” now seems common in games, that’s relatively recent; combined with multi-year development cycles in these so-called “Agile” shops, there hasn’t been much of the learning and reflection that underpins Agile. On top of this, Agile is in a period of maturity right now and is being appropriated by project management, so it is difficult to innovate in the methodology space to come up with an alternative to something like eXtreme Programming that works in game development.
Number four is pretty interesting: Game sequels are not iterations. It is very common to build up mountains of debt to ship a game, and then throw away and rewrite those mountains for the sequel. This worked okay because sequels were usually much more disruptive than innovative so there were more opportunities for rewrites. In contrast, consider that the MS Office UI stayed basically the same from 1993 to 2006. Now as games are entering a loosely defined “software as a service” model, our development priorities must change. We need to be able to iterate month-by-month on the same codebase and pull things forward. This is a new set of skills we need to develop.
There are a number of smaller items that are less important but still should be pointed out:
- Game development hasn’t embraced open source and is on Windows. Many developers and executives I’ve met have a distrust of OSS (CCP’s use and support of Python and other OSS is a source of pride for me and others here) and the majority of game development is on Windows. The Agile movement has strong roots in OSS and Linux, so aside from the cultural differences between the two communities (which should not be underestimated), there was just a lack of engagement between game developers on Windows and Agile evangelists on Linux.
- Game development reinvent wheels. The availability of lots of excellent open source middleware has given non-game developers a leg up on focusing on their core product. If you had to develop your product and webserver, you’d incur not just the cost of developing both but of splitting focus. Game development has historically done a poor job of using middleware and has often reinvented the wheel; this has probably historically been due to the desire for maximum performance and ridiculous deadlines and business models. With more hardware to spare, I suspect this will change and we’ll see things like HTTP used between client/server instead of custom RPC stacks.
Reasons Agile Game Dev is not Tricky
Finally, there are a number of arguments I have thought over and rejected, including:
- Games are art and art cannot be iterated on like other software.
- Games require too much ‘infrastructure’ to make anything playable.
- Games want users to spend time, not save time.
- Games are impossible, or at least significantly more difficult, to test.
- Fat clients are difficult to distribute.
- Frequent releases are confusing for games, which are traditionally content-heavy.
Read: Complexity Thinking:
By Dave Snowden
Look up: Cenefin