During QAI’s Quest conference last week we participated in a workshop aimed to help managers improve their test planning process. The workshop noted that there are several important areas to test planning including: identifying test objectives and scope, assessing and accounting for risks and contingencies, determining component/application priorities, and estimating the size/length of the test effort.
Last week we spoke to a company attempting to integrate test automation into their Agile development process. Confusion abounded when it came to the plethora of tool choices. To add to their uncertainty, they were unsure which team within their group would have responsibility for the selected tool’s implementation and usage. This organization knows they…
In February of 2001 a small group of software development pioneers and thought leaders gathered in the mountains of Utah to create a set of four key values and twelve principles better known as the Agile Manifesto. Over the past nine years these ideals have grown throughout the software development community to spawn “agilistas” throughout the world as well as a host of conferences focused on agile concepts.
Chances are, if you are responsible for the testing of web applications for your organization, you’ve explored or at least heard of Selenium as a potential automation tool. And why not? It’s open source, so no sticker shock on licensing fees. Better yet, no yearly maintenance fees.
Matt Kortering of Universal Mind, wrote a blog post about How UX Fits Within a SAFe Environment. Lately I’ve been thinking about and writing about the scaling models, so a part of this fits well with current themes.
In my previous post I shared about experience I’ve had in “connecting” UX activity into Scrum development teams. I tried to explain a pattern of collaborative partnering over either embedded UX in the teams or independent UX outside of the teams.
I thought I’d share another story that illustrates an aspect of these ideas.
I’ve shared agile methods for over ten years at conferences and workshops. One of the top three questions I always receive from attendees is:
Does Agile work with distributed teams?
I remember the threatening email as if I had received it yesterday. I was in my home office on a Saturday when it showed up in my inbox, a message from one of the world’s leading scrum trainers and coaches. Basically, he threatened my certifications in the email unless I “ceased and desisted” talking about hardening sprints.
A few years back I was coaching a large group of Scrum teams at an email marketing SaaS firm. The group had been practicing Scrum for over four years and had become a high-performance agile organization. Most of my efforts focused on fine-tuning from the perspective of an external set of eyes. Working with this organization and its development teams was a privilege.
I was at a conference not long ago speaking on and sharing various agile topics. After one of my presentations, a young man stopped me to ask a few questions. We struck up a nice conversation that eventually discussing sprint dynamics within Scrum teams. I mentioned that I usually coach teams toward declaring their sprints a success…or (pause for meaningful effect) …a failure.
I do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant based on whether the team achieved their Sprint Goal(s). He was visibly upset with my view. He said they (he worked at a well-known Atlanta company) had never failed a sprint. Never! They could not, nor would not, use that WORD in their culture.