Category: Quality

Getting to Done

| By David Hawks in Agile, Business Analysts, Coaching, Lean, Process, Product Development, Product Owner, Quality, Scrum | 0 Comments

Part 5 of 6 in the “Double the Value in Half the Time” series based on David Hawks’ presentation from Keep Austin Agile 2015. Stay tuned for subsequent posts…

The fifth problem… we’re not getting things done. This is the Scrumbut part of Scrum. “Yeah, we do Scrum but we carry over stuff every sprint. The work just doesn’t fit in two weeks.” We have to figure how to break work down so it can be finished in a sprint. If not, we’re not getting to done and we’re not getting that potentially shippable product increment.

Read More »

5 Good Habits of High-Quality Scrum Teams

| By agilevelocity in Agile, Coaching, Process, Product Development, Product Owner, Quality, Scrum | 0 Comments

Kent Beck said it best: “I’m not a great programmer, I’m a pretty good programmer with great habits.”  What are some of these habits which help product development go from good to great?  Beyond test-driven development and SOLID design principles, there are five good habits that will improve the Read More »

Legacy Applications: Lessons in Coupling

| By Mike Lepine in Agile, Quality, Technical Practices | 0 Comments

I struggled with a number of potential topics for this blog before settling on this one. I understand this isn’t a flashy topic like a comparison of JavaScript MVC frameworks or centralized logging solutions; however, I’ve been working on-and-off with legacy applications throughout my career and have come to truly realize the constrictive nature of coupling logic. Avoiding coupled applications can save your sanity and possibly your business as well. Read More »

An Effective Approach to Agile Development Team Challenges

| By agilevelocity in Agile, Quality, Technical Practices | 0 Comments

A Team’s Agile Development Journey

What typically happens when a software team adopts agile values and principles and implements a framework (such as Scrum)? Normally, after some initial learning, an early positive impact is common along with a feeling of progress. But the team soon encounters new challenges as they realize their journey has only begun. They must now take ownership of their improvement.

Read More »

We’re Hosting a Coderetreat on November 15th!!!

| By agilevelocity in Agile, Quality, Technical Practices | 0 Comments

Coderetreat LogoAgile Velocity will host and facilitate an Austin location participating in the upcoming Global Day of Coderetreat 2014 on November 15, 2014. We look forward to sharing this experience with the local community as well as others worldwide.

Our Technical Player-Coaches regularly engage in deliberate practice to improve skills and hone their craft. While some forms of deliberate practice (e.g. code katas) can be effective when done individually there is also tremendous benefit from actively practicing and learning with others.

Read More »

Courage and Craftsmanship

| By agilevelocity in Quality, Technical Practices | 0 Comments

Last week I presented a workshop session called Courageous Software Development Through Craftsmanship (Slides) at Keep Austin Agile 2014 here in Austin. It was a great crowd both at the conference overall and in the session. A few people I talked to after the session said they couldn’t make it and wanted to learn a bit about the topic, so I thought I would write a blog post about it.

IMG_0178
Attendees creating a model of software built without courage

Read More »

Automated Testing for Legacy Software Products

| By agilevelocity in Quality, Technical Practices | 0 Comments

Many times, we experiment with ideas and processes on new, or “greenfield”, projects.  When starting something new, it is human nature to start with a clean slate and go from there.  However, this is not always possible when automating testing.  By nature, software features are first tested manually, most of the time followed by scripted test cases, and then the QA team starts thinking of ways to automate the testing.  This just makes sense.  I’ve heard it said “the definition of a legacy application is one that does not have any automated tests.”

So, you know you need to automate some of your testing. Read More »

« Older posts