Sometime ago I saw a question posted on a social media site, “Why is Agile hard to adopt?” My initial gut response was surprise. The basic practices of agile are relatively straightforward, so what’s hard? Driving an agile culture, or getting an organization to “operate with agility”, yes, that’s not trivial and it takes time for teams and individuals to “think agile“.  My conclusion is that agile is not hard to adopt, but maturing a disciplined agile practice that leads to an agile culture, operating with agility, or achieving a truly agile organization takes significant disciplines and practice maturity.

Let me illustrate this with a few examples. Below are three key practice areas that agile organizations need to mature in order to operate with agility.

1. 1. Getting stories and requirements written and reviewed on time – Teams new to agile will often site that changing stories mid-sprint or having ill defined stories committed to by the team is a key barrier to getting stories done and accepted at the end of a sprint. This is particular detrimental if an organization has multiple agile teams working collaboratively, or if the organization has distributed agile teams with members at different locations and time zones. The simple and obvious answer is to get stories “locked” at the beginning of the sprint, but this is easier said than done. It implies the team has an agile planning practice with a cadence aimed to finish writing stories, complete having acceptance criteria defined, insure the product owner accepts the story, and provide sufficient time for the team to review, ask questions, and size the story. If you’re writing stories up to the last possible day before commitment, or worse, committing to placeholder stories that get better defined during the sprint, then shifting to more disciplined agile planning practice takes work.
   2. Insuring QA is part of the team – Agile teams commit together and get things done together with quality best defined by acceptance criteria and organizational standards. But teams saying things like, “The story is done, we just need QA to review it after the sprint” are missing a key discipline in agile software development – quality is the criteria for defining done. It implies that QA members are part of the team reviewing stories, asking questions and sizing them. Why? Because some stories have more significant testing implications than development tasks. It also means that teams have disciplined practices to insure QA members can do their jobs during the sprint such as developing unit tests, finishing stories early in the sprint, insuring frequent code check-ins and pushes to QA environments, and investing in QA automation.
   3. Partnering with the Product Owner – Partnering may be an elusive, difficult to achieve relationship depending on the organizational structure, pressures that the product owner feels on delivery timelines and scope, individual perceptions on business value and having a shared understanding of what is most important for the business. Partnering implies balance, for example, that technology teams can respond to questions on why a story is expensive or why addressing an identified area of technical debt is important and important now. It also implies that the product owner invests time to express her vision, that he can respond to questions on why a particular feature is important and prioritized, that there is an open and healthy dialogue to explore multiple solutions to a prioritized feature so that tradeoffs are considered, and that there is reasonable priority applied to technical and support needs. Does the product owner think markets or need help targeting minimal viable product? If not, agile technology leaders have some teaching and mentoring to consider.

Hope this helps!