Related Content
How to Survive a Bad Boss It can be miserable to have a boss who takes all the credit, treats employees harshly, micromanages, abruptly changes priorities, or never provides direction. Naomi Karten shares some tips for surviving a bad boss. Remember that what doesn’t kill you makes you stronger. |
||
Time Management for Developers and Testers We all have the same amount of time—and in that way, we are all equal. However, some people are more productive than others. Brendan Quinn looks at various time management tips and tools and how they can help software developers and testers become more productive. |
||
Business Analysts: Your Team Is Your Customer, Too The most important customers of business analysts are the team members that create the solution. Secondary customers of the business analysts are stakeholders, sponsors, and end-customers of the product. Scott Sehlhorst explains what it means to think about your team as your customer, too. |
||
Making Executable Documentation a Reality with DSLs A domain specific language (DSL) allows a development team to code in a language that business understands. This makes the syntax readable by technical and non-technical individuals alike. If your project is suffering from the overhead of excessive documentation, increase your velocity with a DSL. |
||
Why It's OK to Occasionally Say "Um" or "Uh" Filler words are a natural part of human speech. In informal conversation, people tend not to even notice them as long as they’re not excessive. Naomi Karten explains how the occasional "um" and "uh" are natural, human, and part of everyday life. |
||
Validating Requirements with Given-When-Then When identifying requirements, it can be really tricky to develop a good understanding of how software should behave. Scott Sehlhorst looks at the Given-When-Then approach and how it allows teams to combine the benefits of incremental development with the benefits of getting it right the first time. |
||
How to Benefit from Mistakes Mistakes happen for all sorts of reasons, such as quick reactions, fatigue, bad advice, lack of training, and confusing instructions. Naomi Karten explains how we can benefit from our mistakes because it’s from them that we’re reminded how we could be better—provided, of course, we pay attention. |
||
Estimation on an Agile Software Project Estimation is hard work, and people aren’t naturally good at estimation. But without an estimate, it’s hard to know how far off you’re likely to be. Estimates in the context of an agile project can help you better set expectations and improve stakeholder’s confidence in when you can deliver. |