This article is the second in a series about Agile Planning Circles, the way to drive strategic product development. The first, which is about the process, can be found here and should be read before this one to get the full benefit of the artifacts and tools layered on top of the process in this article.
One of the basic ideas of Agile Planning Cycles is that decisions about future features should be made in a direct feedback loop with the users because only here maximum value with the least effort can be created. Since the Product Owner (PO) and the team(s) are there, they should be able drive the process from Strategy (the red circle above), through Design Thinking (the blue circle) and Lean Startup experimentation (the green circle) to release and the end of the Agile circle (orange).
The Product Backlog as a Collection of Artifacts
How can the PO/team be the driving force through all the circles? It is not enough to bring their long ordered Product Backlog into discussions with different stakeholders to stay aligned across the various abstractions of the future of the product from corporate strategy to detailed User Stories. Continue reading “Agile Planning Circles – the artifacts”
– or how to tie Product Strategy, Lean Startup, Design Thinking, and Agile together.
Scrum is a simple and yet powerful framework, but one artifact, The Product Backlog, is too simplistic to capture the future of a complex product. Likewise, Refinement is insufficient to ensure the balance between the strategic direction and the deliveries on the short term. As a consequence, it is hard to maximize the value for the users. The main reason is that a simple Product Backlog does not ensure enough transparency to engage stakeholders at different levels in collaboration around the value creation.
That said, I think the Product Backlog is a powerful concept. Enforcing an ordered list of product backlog items (PBIs) with higher prioritized PBIs refined to more detail at the top and less valuable coarse-grained PBI’s at the bottom and an understanding that the success criteria is not to deliver everything, are both significant steps forward compared to fixed scope projects.
However, with today’s complex products the ordered list of PBI’s is either too small to be explicit about all the ideas that can generate the value or too large for anybody to consciously pick the most valuable ideas to develop. Pretending that all PBI’s (fine or coarse-grained) can be described in the same way and simply compared as such is an illusion.
So, how do we ensure that we are refining and developing the most valuable stuff if we have lost the overview? Continue reading “Agile Planning Circles”
For many years, Agile has mainly been about the iterative and incremental process, a couple of new roles, etc. Over the last years, as Agile has increasingly become about companywide transitions in large companies, scaling this process and roles has gotten a lot of attention. Agile has gone from what could be illustrated like in the diagram to the left to the one to the right on the figure below.
However, I have observed that while we try to deal with the increased organizational complexity by applying scaling frameworks, we still struggle with the obvious misalignment between agile and traditional company culture and complex IT-architectures. After agile transitions in large companies, we often still have:
- very large projects with many people
- people working on several projects at the same time
- component teams handling a systems layer or a component determined by system architecture rather than user perspective
- people in many locations working together
- handovers from business to IT in the portfolio process
- longer release cycles
We call whatever it is we do Agile, even though it is not significantly more flexible or productive than what we had before.
Continue reading “Agile is Organizational (Re-)Design”
I have learned over many years of implementing Agile that words, and the images they create, are crucial for your success as change agents. To succeed, it is important that you can explain, what is going to happen, and how it is going to happen in a meaningful way.
I have been heading several of what we called agile transformations without deeper reflection on why we picked that word. I guess we just followed the majority of the agile community without considering the impact that it would have on our efforts to help the organizations to become more agile.
Which images appear in your imagination when you hear the word transformation?
The most used illustration of transformations regardless of kind, is the one from being a caterpillar to become a butterfly. Why’s that?
It visualizes a radical change in form, appearance etc, the result is one of the most beautiful animals on earth and most of us associate it with warm summer vacations. All the way through attractive. The butterfly is also much more agile and free than the slow caterpillar.
And no doubt: Becoming agile is a radical change for large corporations. It is not just employees put in teams doing Scrum events. It is a much more profound change of every part of the organization including the company culture. To describe the extend of the change required to be agile, the word transformation and the image of the butterfly is a good metaphor. The agility and beauty of the butterfly is also an attractive image for the end result of an agile transformation. But does it actually reflect the process of becoming agile?
Continue reading “Forget all about Agile Transformations”