“I have been asked from a lot of developers “What is responsive design all about? How does it work, and how do I do it?” In this article I’m going to try to explain responsive design and how that relates to media queries.”
In my experience delivering high velocity, critical business projects, I have worked in environments that have traditional software development approaches as well as environments using agile development approaches. While Scrum has a Product Owner role, every organization is unique and hence their adaptation of roles when they are in an agile environment differs in how the business and IT interpret these roles. Lack of clarity of these roles often results in team members and stakeholders becoming frustrated as they constantly step on each other toes. Here are three key questions that differentiate between the following potential roles at scale that are involved in bringing product direction and building a viable backlog. These roles collectively can work together to help shape the backlog:
If you’re a CEO of a company, agile and scrum should be very familiar to you. If not, you run the risk of losing productivity and profit in your business. The top 3 challenges for CEOs who are driving change in their organizations to meet with shareholder expectations are:
- To prepare organizations to respond to market volatility
- To foster growth and innovation
- To develop human capital
Scrum is a framework comprised of roles, events, artifacts and rules along with a set of values to be lived by Scrum Teams. We have seen Scrum done well and, in many instances, Scrum not done so well. Here's our insights into some of the more common anti-patterns where many Scrum Teams lose the intent, and more importantly, the personal and business impacts that Scrum could bring to their teams and their organizations.
Agile frameworks, like Scrum, are generally easy to understand. With many teams where we have taught and coached, there are some common mindset and practice tweaks that make a real difference to productivity. Here's our top 3 easy fixes to boost the level of productivity of your agile implementation.
1. Establish Team Norms - When teams first form as new teams or when the composition of a team changes mid-stream, many teams skip this step of establishing (or re-establishing) Team Norms. Without this critical team discussion, team members have to discover through time, usually too much time, what expectations they have from each other on how to work and interact as a team. This usually leads to passive tolerance of bad team behaviors and formation of cliches (sub-teams) gossiping about the dysfunctions in the other team members. Alternatively, make sure to take a break from delivery and hold a 2-3 hour Team Norms session to air these expectations. The Team Norms session should talk about values that team members hold dearly, expectations on logistics for how the team operates, and a solid airing of how the team wants to deal with conflict. You should expect that these discussions will be challenging. However, on the other side of establishing Team Norms, you will have a team that has clarity on how to work together as a whole team. With that clarity, you will find that the level of team dysfunction will be significantly reduced, and conversely, the productivity of the team will rise and a foundation for continuous improvement in the team is now possible.
2. Measure and drive your "Ready-State" backlog - Agile is not just about the software development and testing. When Agile is really working well, it is about the flow of product ideas moving rapidly to production-ready, customer-consumable product updates. One very common productivity-killer in Agile teams is not having enough well understood, "groomed" backlog when iterations / Sprints start. This lack of "ready-state" backlog leads to teams struggling during planning (i.e., Sprint Planning) to know what they are supposed to build and how to build it. Half-baked planning leads to ineffective iteration execution and often with product that does not meet the customer need, therefore leading to re-work. There are 3 easy steps to inject a new level of discipline into your team to get a solid ready-state backlog. First, establish a clear Definition of Ready - which criteria should backlog items meet in order to be declared "Ready". Second, define a backlog grooming / refinement flow with clarity of roles / responsibilities for moving backlog items from "Grooming" state (i.e., backlog item needs additional refinement) to "Groomed" (i.e., backlog item is teed up for final refinement by the whole team) to "Ready" (i.e., the whole team has declared that the backlog item meets the Definition of Ready). Third, the Backlog / Product Owner should report regularly in daily standups the depth of "ready-state" backlog. The depth should be measured in how many iterations / Sprints worth of backlog are in the Ready state. If the "ready-state well" is getting dry (below one iteration's worth), this should be a signal to the team to jump into re-filling the well and put more energy into grooming additional backlog. With a solid ready-state backlog, teams will find that planning will be more effective and that iteration execution will be clearly aimed at the target established from planning. With clear goals, the team will be wildly more productive towards achieving real customer-valuable delivery.
3. Take retrospectives seriously - Too often, teams take the "check the box" approach to retrospectives. Given retrospectives are a defined part of Agile frameworks like Scrum, teams almost feel forced into holding retrospectives and cannot wait for this meeting to be done and over. The skepticism or boredom with retrospectives are usually associated with one of a few causes - no real action taken from the retros or re-using the same format for retros over and over. For teams that take retrospectives seriously, they are the critical enabler for a Culture of Continuous Improvement. Teams that embody a real Culture of Continuous Improvement have no ceiling on how productive they can become. There are two easy steps to make retrospectives impactful for your team's productivity. First, establish as part of your Team Norms (we talked about this above) a commitment to hold the team accountable for identifying and following through on at least 1 improvement from each retrospective. You can build this accountability into your retros by starting each retrospective with a look back on the improvement commitment made in the last iteration and having a transparent discussion on how the team did on acting on that improvement. Second, if retros are getting stale and boring, spend some time to read Agile Retrospectives (Derby / Larsen), understand the suggested structure for conducting retros and look for new ideas for different activities to "mix it up" at your retros. The structure suggests conducting a Closing to reflect on the retrospective itself - a "retro on the retro". This might seem like overkill, but you will quickly find the approach and activities for retros that really resonate with the team and produce valuable improvements.
These 3 fixes can really get your team to the next level of productivity. So, step back and take a critical view if any "tune ups" could be valuable for your team.
What is Agile? And, how can it make you faster, more innovative, and competitive?
In today’s business environment, how is your organization remaining relevant? Is it investing in innovation? Is your organization feeling pressures to deliver products to the market faster in order to remain competitive? How are you adapting your product to the market demands?
As a product owner, I am constantly challenged with writing user stories that meet my stakeholder needs. A key deliverable from a Product Owner is having user stories with crisp acceptance criteria. Having clear acceptance criteria enables the scrum team’s ability to deliver high-quality software. It also enables the team to make commitments toward sprint goals while ensuring that the business is getting high value deliverables based on the decomposition of the highest priority epics. The challenge in writing good user stories is always the amount of details to add to a user story. A good user story should have enough details to understand the business intent, the user roles, the goal and the depth so that the team can understand it to produce a workable prototype or software and the business can understand it.
Teams are an intricate balance of skills, cooperation, leadership and willingness to go the extra mile to make a quality product. Each grouping has individuals with specific roles and responsibilities, as well as a chain of command to help guide the team to success. Within a testing team, the QA Engineer plays an integral part that helps testing run smoothly and ensures that all projects are thoroughly evaluated.
Although the QA Engineer isn't the top dog in the team, he or she does report to the QA Manager. The person in the QA Engineer role essentially takes the requirements and test strategies and generates test plans. But that's not all. These individuals also execute these tests, leverage QA testing tools to report issues and analyze test results to mitigate problems and create better tests. This is obviously an important position to be in, but many don't fully understand what capabilities are needed. Let's take a look at some of the essential skill requirements for a QA engineer:
- Communication
- Product Understanding
- Coding and Creativity
- Automation