Agile Horror Stories: Trick or Treat
Differences Between agile and Agile Wearing the Agile Costume The agile Mindset: Don't just go through the motions!
Differences Between agile and Agile Wearing the Agile Costume The agile Mindset: Don't just go through the motions!
Agile Value in the Journey Agile Value in Agility Agile Value in Team Transparency What if the enterprise won’t change? Is it worth it to haveAgile 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 transformationswill only be effective as far up...
In thelast blog, we made the case that everyone on theagileteam owns quality and provided some ideas on how team dynamics can help build quality into the product. In today’s post, we will discusssome 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. As we noted in our previous post,waterfall tended to equate testing and quality, which can lead to all kinds of bad habits – the main one being...
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. Present Day Quality Fast forward to today, on an agile team and the...
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? Often times, when a company begins their agile transformation they think they are BEING agile when in fact they are justdoing it. Being agile takes...
Key Takeaways A Different Take – 4 Keys 1. Starting Properly 2. Committing to Agility 3. Collaboration tools are important, but… 4. Compensation structure and incentives Wrapping Up 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 onmanagementand say you...
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 withsome simple and pragmatic advice foragileorganizations and teams when they’re trying to sort out how architecture fits in agile contexts. 1. Allow Architecture to Emerge 2. A Picture is Worth… 3. Treat it Like a Product 4. Everyone is an Architect and Everyone Owns the Architecture 5. Keep it Simple and Connect to the Customer 6....
In one of our previous blogs the term “just enough” was used to portray the idea that we (whether you’re in a testing, dev, or management roll) should help everyone on the team to resist gold plating and actively help and encourage each other to do just enough. And that by doing the “right just enough” we are BEING agile. But why? You may ask, is this term so important? Because it plays into the team’s overall velocity. My friend and colleague, Shaun Bradshaw, and I were recently...
After 20 years in quality assurance, I’m still surprised to hear about companies that don’t have formal QA processes. Even more surprising are the companies that say having a QA function is not necessary. Maybe they are a newer tech company with a tiny, tight-knit development team and the software complexity hasn’t reached a level where defects reach a critical mass or perhaps the company doesn’t support a formal process even though it’s happening in some manner. For me, it is akin to saying...
1. Seek Out Advice from the Experts, Inside and Outside 2. Communicate Often and To a Wide Audience 3. Know What the Risks Are and Call Them Out ASAP 4. Get to Know Your Product Owner 5. Don’t Get Caught Up in What You Think You Know 6. Get to Know Your Developers 7. No More Multi-Tasking 8. Embrace the Retrospective 9. Slow Down (a Little) and Enjoy the Ride I spent eighteen years testing before I ever worked withagile. When I suddenly found myself transitioning to an agile team...