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.
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 »
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.
Agile 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.
Behavior Driven Development is the process of writing high-level scenarios verifying a User Story meets the Acceptance Criteria and the expectations of the stakeholders. The automation behind the scenarios is written to initially fail and then pass once the User Story development is complete. Read More »
In the first article of this two-part series, we discussed how to define scenarios for testing. Now, once this is done, the Testers can partially implement the new steps to fail.
For example, adding assertions that a file exists on the file system.
Or, writing code returning a negative result for now. Read More »
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.
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 »