Repeated software-development tasks are becoming automated through the application of Continuous Delivery and DevOps. If developers are taking more and more testing responsibilities into their hands, I wonder what will be the role of traditional (manual **only**) testing and testers moving forward?
A while back, Henrik Kniberg published an excellent case study on Scaling Agile @ Spotify. Though case study is specific to Agile scaling experiences at Spotify, some practices are equally important for smaller teams as well. This post tries to capture the essence from smaller team’s perspective.
A lot of organizations still works in functional silos.
For instance, in a bank, there may be one team for web banking, another team for home-loans and yet another one for mainframe based core-banking. Business features however in general cut across all these teams.
One of the key fundamental elements of Agile is its focus on delivering a testable or demonstrable end-to-end functional slice that provides business value. This approach is the key catalyst of some behavioural, cultural, and structural changes.
As a product owner, I am interested more in the working functionality of a product rather than the individual goals of team members. For instance, just the front-end of a user-story is of no use to me. Even if the developers finish coding, I cannot use the product if it still needs to be tested. This implicitly means that cross-functional team members have to collaborate and help each other to attain Sprint goals. Hurry and Read the rest of this post!
Often, I get to hear questions about level of details that need to go in the product backlog stories. How detailed should be the acceptance criteria? or how small the story should be? We all know stories matures with time. I really like this post on user story life-cycle. Please take time to read this. Let’s consider an example now.
User Story example: As a Project Owner(PO), I should be able to transfer complete project ownership to my connection, with my role remaining to be just a project creator(author) after transfer.
Note: At the first sight, it is tough to say whether this is a story or an epic. When this story comes up in backlog grooming meeting, teams might completely miss the magnitude of such stories. Hence, as the product becomes bigger it is wise to start detailing stories by adding acceptance criteria earlier in grooming meetings itself. Impact of every new story gets wider as product becomes bigger which often gets missed by the team.
Every Agile team has to deal with different emergencies next to their regular work. Every team dream of achieving sustainable pace comes with nightmares of production emergencies/defects, support and maintenance tasks within a sprint which takes focus completely off the sprint goals. The goal of this webinar is to see different approaches team can take to absorb a reasonable amount of uncertainty, striking balance between robustness and speed within the sprint.
Also we will discuss about how to deal with “Pivot” in lean product development. In this state, product has to go through a course correction in terms of vision, market segment and features. This is almost an emergency on business side. In webinar, we will see how engineering teams need to do course correction in their approach too.
Audience will learn:
How to plan for production emergencies during a sprint
How to apply strategic and tactical thinking to handle changes
How engineering team needs to deal with development when product is in Pivot
We know “Testing As An Activity” is important, and why we should all test. The old axiom that “Testers Test and Programmers Code” is so outdated now and everyone needs to change. Testers are the testing experts in a team, and can help enable the whole team to own quality but they are certainly not the only one’s who should be testing. Like, developers need to contribute towards testing by unit testing their code and also pair testing to minimize defects and minimize test – defect-fix cycle.
Testing in agile, addresses the processes that produce software and also products of those processes. Hence I ask my teams to not just focus on validating software after development, but also check processes that produce software like, quality of stories, requirement/impact analysis, acceptance criteria(using behavior-driven-development to address “3 amigos problem), and more.
Take a look at our agile testing workshop which is a detailed 2 day course which focusses on test automation strategies, lean approach to defect prevention, various tools and techniques to automate, BDD(behavior-driven-development) and how to use various frameworks – Linear Scripting, Test Library Architecture, Data-Driven Testing, Keyword/Table-Driven and Hybrid automation frameworks.
In our last post, we discussed about how to break performance measures into team and individual measures to bring more team behavior orientations into appraisals. Today, let’s talk about addressing other two issues: feedback frequency and how to make feedback effective. Agile thinking is based on building frequent feedback loops within your teams and organization. […]
It’s well known fact that physical Scrum Boards provide many benefits over their electronic counterpart. With physical boards current sprint state is transparently visible to anybody in the team and to the stakeholders. As a team member you no longer are required to explain someone what exactly the team is focusing on right now as […]
Appraisals! How many of you dread this word? This is the only time in the year that you get to bargain for salary increments, everyone end-up negotiating to their best. Appraisals are closely connected with salary raise/increments, bonus payouts and it’s feedback intent takes the backseat. There are three major issues with traditional approach to […]
We discussed about committing fixed number of story points and swapping any additional scope with existing backlog in our previous post “Agile for Fixed Bid Projects“. This is a great way to maximize value with minimal change in timelines and budget. This works well when there is a trust existing between product and engineering, and […]
The basic premise of Agile methodology is to develop software in an incremental and iterative fashion based on regular feedback that is received at the end of each sprint (i.e., 2-4 week cycle). The resultant feedback of a sprint demo often translates into change, and Agile methodology has a key tenet around embracing change. The […]