Being an Agile team is all about adopting the Agile frameworks to the core – both in project management and team collaboration. It is all about efficiency and effectiveness, which means adopting methods to optimize resources, make the most out of teamwork and, especially, mitigate or avoid loss of time and costs.
But whether you adopt Scrum, Kanban, XP or any Agile framework, in the end, it all depends on the teams involved, the leaders managing the project and the customers at the receiving end. In order to make any project successful, the foremost thing you need is a competitive, skilled human resource.
[Taking pride in your work can inspire you, but if not kept in check it can cause long-term challenges for the client or corporation you serve. Are you THAT person impacting your corporation in a negative way?]
Taking pride in your work is something we all should be doing, regardless of our career choice. Failure to do so leads to not only short-term challenges with your decisions, but long-term issues as well. At the same time, it is possible to have a great deal of pride in your work that leads to long-term costly issues as well.
I was recently asked about the composition of a high-performing Scrum team. Why is it that some Scrum teams consistently deliver on their sprint commitments regardless of the difficulty of the work and seem to have no limit to their ability to increment their velocity, While other teams struggle and seem to miss more sprint commitments than they make? I must admit that in a large global organization, even among mature teams, I see widely varying degrees of success in our Scrum teams. We know that a Scrum team can face stubborn technical challenges. Given the difficult work and the self-organized nature, rich team conversations and innovative thinking is an advantage. I recently read that team diversity improves decisions. Let’s look and see if it contributes to a high performing Scrum team. But first, let’s define a healthy team.
A healthy Scrum team delivers an agreed amount of work, while enforcing a standard of care. The work is defined by the Product Owner and has value to the stakeholders. Accountability to the stakeholders is paramount but is trumped by accountability to the team collective. The team is a “small, co-located, self-organized, self-contained, value-driven, group of full-time team members who are organized around a mission. Their job is to produce high-quality results at a sustainable pace.” (Scrum Team, ScrumDictionary.com. Feb, 2018)
That moment when you’re neck-deep in a task, only to learn that a teammate has already completed it. Or when you thought someone else owned a task and they thought you owned it. As you mentally tally the hours of wasted time, your stomach sinks lower and lower.
Poor communication is toxic for any team. Fortunately, agile development teams already know how to safeguard their productivity. It’s called the “daily stand-up”, and it’s becoming increasingly popular amongst non-technical teams like sales and HR – those who are savvy enough to adapt and adopt agile practices, that it.
If you’re among the uninitiated, no worries: the concept is dead-simple. You gather your team for 5-10 minutes to share updates on what each person is working on and what they plan to tackle next. That’s it. In just a few minutes, you’ve insured yourself against duplicated effort and dropped balls.
It’s no surprise that coordination and communication within and across teams are critical to productivity. But it’s surprising how hard they are to get right. Consider that 86% of execs, employees, and educators blame ineffective communication for most failures in the workplace. And those failures ain’t cheap. A business with 100 employees loses an average of $528,000 annually clarifying lousy communication.
So just throw a few emails at it. Job done. Right? Wrong. Workers spend 13 hours each week on emails as it is, and 96% say at least a few of those hours are completely wasted time that make their “real work” workload feel heavier. In other words, more email equals more stress – and stressed-out employees take almost twice as many sick days, and are less productive when they’re in the office.
Stand-ups are a great alternative to email because they’re not just quick, they increase engagement between workers. Plus, they’re fast-paced and high-energy, both of which give the ol’ daily routine a nice shot in the arm.
If all this sounds far too vanilla for your tastes, try one of these variations.
Conduct your stand-up around a task board (e.g., kanban board, Trello board) and run through each task. Discuss what needs to be done to move each one along, whether it makes sense for someone to help out, and roughly how much work is remaining.
Show and tell
Instead of using the 10 minutes to update each other on the status of your work, use it to share tricks of the trade or that cool article you read this morning on the train. If nobody has anything to share on a given day, you can always dig into some data – how are you tracking on your OKRs? any interesting spikes in traffic to your site lately?
All for one, all distributed
If your stand-up includes a mixture of remote and co-located people, take a page from the folks at Trello: have everyone join the meeting via video conference. This levels the playing field in terms of how easy it is to hear and participate.
Being transparent about what you’re working on is the easiest way to ensure things keep moving smoothly – for everyone. Try a stand-up with your team today (or share this post with your pals over in finance/marketing/legal/HR). It’s a great way to put the “happy” back in this week’s Friday happy hour.
When it comes to developing products, no one knows a product inside and out better than a developer. Developers know a product’s advantages, flaws, uses, and potential uses. It’s their job to know, and it’s in their bones to know.
Listening to what developers have to say has always been important, but perhaps never more important than it is today, in the omnipresent digital age.
Every day the computer and networking industries become more software-driven. Meanwhile, the Internet of Things (IoT) industry is swelling. Gartner predicts that by 2020 there will be more than 20.8 billion connected IoT devices worldwide. From cars to clothes to products yet to be identified, billions of IoT devices will be developed that require programming, from the device down to the item or app that collects and displays the data to end users. Competition will inevitably mount among the many new and existing players in the field.
In a nascent industry such as IoT, developer communities are essential. People with software and engineering skills must be able to develop, explore, and guide ideas into reality, and develop and fine-tune existing products into better products. The developer’s knowledge and input are hugely important.
In any industry, nascent or not, you can’t risk alienating developers. Ignoring their input signals a lack of trust, and trust is the bedrock of good manager-developer relations. They need to trust in your product and what you tell them about your product.
The last thing you want to do is jeopardize the knowledge base that keeps maintaining and developing your products. You also need to keep developers invested and interested in what you’re doing. You need to listen to them.
For that, you need an online community. Communities facilitate listening. Good communities make it easy for developers to contribute and collaborate with other developers, and they provide much-needed formality in the process of soliciting and gathering developer input. Remember, the easier you make it to collect their feedback, the faster you can get the information to your product management and engineering teams.
Good communities not only acknowledge the contributions of developers to the products and platforms they help develop, but also continually look for ways to improve the developer experience. Improvements shouldn’t be made in a vacuum; they should be made with input from the developers themselves.
For instance, a community manager sends out a brief survey asking developers about their recent experience developing a particular platform. The survey isn’t only seeking to hear what the developers liked but also what they didn’t like, what frustrated them, and what they wish had been done differently to make their experience better. The manager follows up with several of the survey responses to dig deeper into the developer concerns.
Then, the manager acts on those concerns, making the following improvements in the developer community:
Community improvements run the gamut, and there are no one-size-fits-all rules or guidelines. The main thing is to give developers the opportunity to voice their likes and dislikes and make sure their input doesn’t fall on deaf ears.
Developers’ input helps you ensure your product meets your customers’ expectations and solves their problems. Their input helps you provide amazing customer experiences, and improve customer retention. Their input is one of your most valuable sources for your product’s viability and longevity.
You need to listen to developers and give them a community where they can contribute and collaborate, and where you can easily solicit, collect, and act on their vital input.
Bob Galen is an agile methodologist, practitioner, coach, and with more than 30 years of experience as a software developer, tester, project manager and leader. We recently sat down with Bob to learn more about what separates mature agile testing teams from the rest, and how leaders can best support those teams in order to consistently deliver working software.
Noel: We hear a lot about the requirement of shortened feedback loops, and development, test, and release cycles that deliver continuous feedback. Continuous feedback is certainly a must-have, but what I don’t hear people talk about a lot is how important it is to actually be able to quickly respond to that feedback, and make informed decisions.
How important is being able to do that, and not just collect or note that feedback, but adjust on the fly to make new decisions, pivots, and responses continuously as well?
Bob: I think this is a really important point, Noel. And it’s not simply related to continuous feedback, but also to the continuous improvement cycle. For example, feedback on adjustments that are raised in team, project, or organizational retrospectives. To your point, our lean-age should be towards doing something about our discoveries, in taking action.
It’s one of the reasons I talk about “stop the line” as a mindset.
If we were part of an assembly line that was building Toyota Corollas and we noticed that current cars were being delivered without rear doors, we would pull the cord and stop the line.
Then what would we do?
I would hope that we would fix the cars. In fact, the sooner we stopped the line, the fewer doors we would have to repair (less rework, less time impact).
But are we done? No!
We have to examine root cause in our process and figure out what is creating the issue. Then we need to…fix it! Only then are we done with the event and can start the line again.
This somewhat contrived story focuses on:
I’d like to reframe the question to focus more on continuous improvement, with a preference for fast feedback, fast understanding, and fast adjustments.
Working software is the ultimate goal and measure of, “Are we there yet?” and, “Are we done?” —Bob Galen
Noel: You gave a session at DevOps East that talked about what makes teams agile teams “mature.” What qualities do mature teams have that other teams may not?
Bob: I guess, first of all, they behave like a team. They have shared goals and they share the work in order to get results. So, skills are not an impediment to collaborating and working together. Activities like pairing on work are commonplace.
Mature teams also hold each other accountable. Accountable to quality deliverables, accountable to each other’s commitments, and accountable to delivery results. You can see this in their work, but very clearly in their retrospectives—where hard conversations are surfaced when necessary.
They also have the courage to challenge outward and upward. For example, if they feel leadership isn’t giving them the landscape to succeed, then they’ll push back on distrust, over-commitment of work, and lack of support resources.
They’re in it together. They succeed and fail as a team. In fact, they defend each other. They help each other. And they work hard to maximize their global strengths and minimize their weaknesses.
And finally, they get sh** done. My friend Josh Anderson spoke about his 3-part hiring requirements for high-performance agile teams during his presentation. His criteria are:
Josh was focused on candidates who could exhibit all three characteristics (the intersection in the Venn diagram).
I think that’s another way of effectively thinking about a “mature” or a “high-performance” agile team. But please don’t get stuck on those terms or goals.
I also want the team to have fun together. To discover the joy in doing great work that drives great customer value.
Noel: You mentioned in your session the need for agile leaders—and other leaders—to have “an increased understanding and respect for software testers and to recognize testers as first-class citizens.” How did it get this bad for testers? How did we get to a point where “leaders” might need to be reminded to do that?
Bob: I’ve been involved in software development for nearly 40 years, Noel. And, yes, that number frightens me from a variety of perspectives.
I think testers have had a second-class citizen rap that entire time. Developers have always been perceived as a value center and testers as a commodity and cost center.
I think a big part of it is many technology leaders come from a software developer background, so they more easily understand the value proposition of development. I’ve actually had the opportunity to lead both development and testing organizations over the years. I also sent myself to many classes so that I could understand the profession and craft of software testing more deeply.
Given that, I think I achieved a much more balanced view towards the value of each. Many leaders lack that broader perspective.
In fact, I think they trivialize the notion of testing. For example, in agile contexts, they think it simply surrounds “checking” user story functionality on a sprint-by-sprint basis. But it is SO much more than that. Or, at least it should be. When you minimize it to simple functional checking, it becomes a commodity that anyone can perform. Or, at least that’s the perception.
They also don’t think of the quality practices that testers can drive, which I discuss in question #5, below.
Noel: You also describe the need for leaders to “understand the power of basing decisions off of the objective evidence of working software.” To me, defining “working” is a little like defining “done,” meaning, extremely difficult. How important is it to learn how other stakeholders define “working,” and then, once you know, does everyone need to define it the same way, or is there room for some variation there?
Bob: I don’t think defining “done” should be the focus. I stand by my comment, and what I’m trying to say is that we, as software teams, often work on many things to build our software. Some of those things include:
ALL of which do not directly deliver value to our customers or stakeholders. In other words, they don’t pay us for the above elements. Sure, all of them are necessary to some degree, but they’re not directly in the value stream.
So, I think the point is not the definition of working software, but the delivery of working software. So that we can determine our direction not from documentation or plans or talking, but from the very thing that we’re building to deliver customer value.
It’s tangible. It reflects the value we’re delivering. The customer can touch it, feel it, interact with it, and give us feedback as to whether it meets their needs and solves their problems.
Working software is the ultimate goal and measure of, “Are we there yet?” and, “Are we done?”
Noel: You’ve talked about how in mature agile teams, “testing is not their only quality practice.” I think that would, at least initially, surprise some people. What, outside of testing helps build quality in, and, secondly, does doing whatever that is relieve some of the burden placed on testers?
Bob: Actually, to be clear, testing is not a quality practice. It is a verification process.
Quality practices are different. They focus on pre-verification activity. For example, the “3-Amigos” is a common practice within agile teams. It’s where developers, testers, and the product owner all work together to vet user stories all along their lifecycle. It’s a collaboration metaphor where each perspective weighs-in on the story definition.
Design reviews, code reviews, and pairing are also hallmarks of quality activities within agile teams. As is working with the customer/stakeholder and product owner to ensure we understand the problem we’re trying to solve.
Sometimes folks refer to some of this as “shifting left” in testing. That is, the testers focus on ensuring that we’re building the right thing and building it right, before verifying it.
Think about it. In many ways, testing is too late to catch defects. Even within the tight feedback loops of agile teams, I’d much rather testers spend some of their time in “up front” activities to ensure we’ve got the recipe right before they focus on testing things.
And yes, if we get the shift-left-balance right, then the testing is more of a by-rote or safety net activity. And it loses its typical, repetitive test-fix-test again nature.
Or, that’s the hope when focusing on building quality in vs. testing quality in.
This is a guest post written by Kat Boogard, a writer for Toggl who covers a little bit of everything — but places most of her focus on career, communication, and self-development topics.
So, you want to be an amazing agile team. Who can blame you? It’s human nature to want to build something awesome, especially when your team is just starting to take shape. You’re in it to win it. You want to release great software—all while making it look easy.
But, unfortunately, there’s no magic recipe, secret sauce, or tried-and-true formula to becoming a truly top-notch team — which is what Agile is all about. It’s supposed to be different and ever-changing depending on each team and its circumstances.
However, there are six key strategies that can help you make your team an awesome one. Try these on for size.
When you think of an amazing Agile team, you likely think of something that functions like a well-oiled machine. And, in an ideal world, that’s how things should work, but that doesn’t mean things will work like that right from the get-go.
It takes a while to get a feel for how people work together and to fall into a system that really flows — that concept holds true whether you’re working as part of an Agile team or not. And according to Tuckman’s “Stages of Group Development”, teams go through several phases: forming, storming, norming, and performing. This process naturally takes time.
So, don’t get bent out of shape thinking that your team is doomed for failure simply because there are still a few kinks to work out. Patience is a virtue.
Agile would be much easier if you could simply set everything in stone, and then know that things would remain exactly the same forever, right? But, as you already know, that’s just not the way it works.
Change is inevitable. A key element of Agile teams is the ability to respond to those changes, rather than always trying to stay committed to a previous plan. The best teams constantly reevaluate their priorities and shift their resources accordingly.
Yes, Agile relies heavily on order and organization. But, you can’t be so rigid that there’s no flexibility for you to roll with the punches.
The beauty of an Agile team is that it focuses more on results and outcomes, rather than obsessing over processes and procedures.
By placing more emphasis on the results, team members feel empowered to make decisions, solve problems, and develop innovative solutions using whatever skills and expertise they have.
It doesn’t matter what type of team you’re working on—everybody likes to feel trusted, valued, and empowered to get work done.
What’s the key word in “Agile team”? You might immediately conclude it’s “Agile,” but the operative word there is actually “team”.
In a traditional team, it becomes all too easy to get tunnel vision, focusing exclusively on your individual responsibilities. However, this just won’t work when you’re part of an Agile team.
In order to be successful, you need to foster an environment where everyone is accountable for the final product — and not just their individual contribution. This allows every team member to recognize that their efforts are contributing to the bigger picture, while also reaffirming the entire team concept to fail together and succeed together.
To be success, foster an environment where everyone’s accountable for the final project.
Here’s the cold, hard truth: It doesn’t matter how streamlined your processes are, or how fast you’re able to churn out software, if you aren’t actually creating the right product. And, the only way to know that you’re on the right track is to gather lots and lots of feedback.
Successful agile teams have systems and methods in place to get their software out in front of customers as soon as possible so that they can collect feedback early on and incorporate it into the product.
Beyond customer feedback, great teams are also extremely transparent with each other. They don’t sweep problems under the rug. They remain completely honest and view any blunders or roadblocks as opportunities to continuously learn and ultimately improve. Holding retrospectives can help a lot to achieve that.
You knew this had to appear on the list somewhere, didn’t you? Ultimately, an agile team is nothing without trust. It’s essential, and it all comes back to the core concept of truly functioning as a team.
Every member of the team needs to trust that others will hold up their ends of the bargain and get things done when and how they said they would do them.
Becoming an awesome Agile team isn’t just a pipe dream—it’s totally doable, as long as you implement these key strategies and remain patient. Give it a try, and prepare to be amazed!
In addition to these tips, there are tools and add-ons that can help your agile team work like a dream. Take the new Toggl for Jira integration, which was developed to help teams better stay in the loop and ensure things are staying on track. Check it out in the Atlassian marketplace today.