Agile transformation starts by individuals followed by teams and at last gets completed by organisation level. This is potentially a long-lasting process with a lot of turbulance. Majority of the people like status quo particularly people who are above a certain level of age. They are quite comfortable in their comfort zone and are not very willing to leave it. I think it’s completely understandable.
On the other hand, Agility is a totaly different mindset. It embraces early and frequent delivery in an iterative and incremental manner. It’s extremely critical that the agile transformation is well understood throughout the whole company not only in technology teams or in part of the organisation. If this is not the case, agile teams will have face many significant impediments and at the end may probably fail. Let’s imagine a case where the product marketing teams are not familiar with agile principles or Scrum framework and in the Sprint review meeting they’ve been made a demonstration of the iteration to be shipped. It’s quite likely that there is a struggle between the Marketing teams and PO regarding the deployment decision of the iteration. PO will very likely to push the deployment so that customer feedback is received and following iterations are improved based on that while marketing guys don’t think the iteration is mature enough to present to customers and might damage the overall image of the product. On such instances, it’s key that decisions that has been made by the PO should be respected by the whole organization. POs those are supposedly selected by the management team, should be empowered enough to have the right level of authority. Without sufficient sponsorship support, POs will be underpowered and lack authority. On those cases it is very likely that they feel overwhelmed and will struggle with the major decision makers.
Okumaya devam et “Million Dollar Question: Are you doing agile or being agile?”
One of the many new practices for organizations going through agile transformation is the move from requirement documents to user stories. I’m quoting from Mike Cohn *:
“User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.”
In the classical approach, there is a requirement document that has been agreed by development and business groups after multiple time-consuming iterations. Even if both parties agree on a document after significant time and start developing the new feature, chances are part of the original scope gets obsolete or changes and things need to be reiterated and perhaps portion of the development efforts have been wasted. This approach is obviously not suitable particularly for time-critical projects. On the other hand, user stories are mutually understandable both for customers and developers and increase the communications between team members and stakeholders. User stories also allow the development team do the practical planning. As Roman Pinchler nicely puts it **:
“User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible;not to impose any overhead.”
Okumaya devam et ““Working software over comprehensive documentation””
One of key definitions of the Scrum framework is “Definition of Done”(DoD). In order to be able to decide when an activity from the Sprint Backlog is completed, the Definition of Done (DoD) is used. This bring all the team members to the same level of understanding about the conditions when a task is completed. The definition of done for our team is as follows:
Any issue in the Sprint Backlog is considered to be “Done” if the analysis, development and validation stages have been completed successfully and the acceptance criteria has been met. The deployment is not a prerequisite for the issue to be considered as “Done”.
Okumaya devam et “From Continous Delivery to Continous Deployment”
One of the key responsibilities of a Product Owner is looking after the backlog and building and maintaining the Product Roadmap. The Roadmap is a great tool that provides a visibility regarding the Scrum team’s work and to materialize where the team is headed to. It’s a good practice to communicate the up-to-date Roadmap with the shareholders often in order to let them know which new features and bugfixes are planned over the coming weeks and months and to notify if there is a recent change on the planning.
We are running 2 weeks-long Sprints. At the end of the Sprint Review session, as the PO, I’m presenting the PBIs (Product Backlog Item) in priority order and ask openly to my line manager and other shareholders if we share the same understanding of priorities. From time to time chances are my management team and/or shareholders comment on the priority of PBIs and ask changes. On those instances, we altogether discuss about the motives of these new requests and get fully aligned. At the end of the review we as the team get either confirmation from the audiences regarding the priority order or have an updated list of priority. Here below you can see the ~3 months Product Roadmap of our team. (I’ve intentionally made it blurry for confidentially reasons)
Okumaya devam et “How to build, maintain and communicate the Product Roadmap?”