Spring Cleaning? Now is the perfect time for agile backlog grooming. The sun is shining; the birds are singing. The tree leaves are back, along with people’s allergies, easily confused with COVID-19. Speaking of COVID-19, millions of people have been forced to stay home over the last few months, and many have started attacking home projects with a vengeance, because they have no place to go except for their local hardware store. Garages have been organized, along with closets, basements, and attics. Yards are now tidied, new flowers and vegetables planted, and the world is generally a cleaner place. The madness even overwhelmed me and I am now the proud owner of a freshly re-graveled driveway (and some seriously sore muscles). Many items on the To Do List have been checked off. Speaking of To Do Lists, (and because I need to get around to talking about agile things) how’s your product backlog?
As an Agile Coach, I often try to simplify things and refer people (and myself) to the Manifesto for Agile Software Development. Almost all agilists can remember at least the first core value, “Individuals and interactions over processes and tools.” Though the introverts might cringe about it, most are also familiar with the principle, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
I love my wife. No big surprise that I would say that publicly, on the record. We have been together for over 32 years, have 3 amazing daughters, and have managed to partner with each other through the good and bad times. Valentine’s Day is a great time to reflect on our great loves, smell the roses, and consume copious amounts of candy. When I think of who and what I love, I have to put Agile on the list, not so much because it pays my bills, but because it contains a lot of concepts that have made my best relationships possible. So, for the sake of this blog “agile love” is a real thing.
I love Halloween. Science may say that autumn starts September 20-something (depending on the year), but in North Carolina the temperatures don’t really get cool until around Halloween, along with the leaves changing and the total Fall experience. I am also a sucker for cheap candy and crazy costumes. When I was young, I loved dressing up and pretending I was someone else for the day. In our modern world, people don’t need to wait for Halloween to wear costumes.
What if the enterprise won’t change? Is it worth it to have Agile teams? I have long felt that certain parties in the Agile community are too quick to judge teams as not being agile because they are forced to function under less than ideal organizational structures. The mantra I was taught (and often repeated myself) was, “The leader is the limit.” Agile transformations will only be effective as far up and across the org chart as there is support from leadership.
In the last blog, we made the case that everyone on the agile team owns quality and provided some ideas on how team dynamics can help build quality into the product. In today’s post, we will discuss some additional ideas on how your software QA teams can work together and ensure quality is on the forefront of everyone’s mind when building a product.
Once upon a time, in the land of Waterfall, the business analysts wrote the requirements, the developers coded the requirements and the Testers tested the requirements. Each of these people sat in his/her ivory tower, um, silo and did that which they had always done since the beginning of time. Quality was thought to be synonymous with testing, and therefore was considered to exist solely in the Tester’s realm.
Are you an experienced tester who has recently joined an agile team? Maybe you have testing experience but until now it has only been on traditional waterfall projects. Are you going through the motions with this new way of doing things but don’t feel like you’re completely invested? Do you even feel like you’re adding value to your team?
My first piece of advice is this: DON’T DO IT!!!
Probably the worst possible setup for a team is spreading them around the country, world, or the universe and expecting them to behave and deliver like a close, cohesive team.
My second bit of advice for those of you that blame it on management and say you don’t have any say in the matter, is: wrong. You have lots of say in sustaining distributed teams or creating another strategy!
Wow, the title sounds quite bombastic, doesn’t it? And I sound quite full of myself, don’t I? Well…perhaps I am.
Nevertheless, I want to go on record with some simple and pragmatic advice for agile organizations and teams when they’re trying to sort out how architecture fits in agile contexts.
In no particular order, here are my guidelines: