At retrospective meetings, we reflect on how our team has been operating, sharing both the good and the bad. We try to identify problems and take actions that solve those problems.
But just as important as fixing procedural problems is giving individual team members the chance to speak, be heard, and “air-out” anything that’s been bothering us. Ideally, we will honestly share our feedback and perspectives, and humbly acknowledge our mistakes. In reality, though, most of our retros fall short of that standard. Here are some common problems and ideas to help work through them. Read more on Tackling Silence, Avoidance, & Negativity in Project Retrospectives…
My long-time girlfriend works as a Business Analyst for an IT company that does agile development. Recently, she asked me what I (as an engineer) look for in an ideal requirements document for a feature.
This hit home for me because I have seen plenty of poorly-defined features on projects I’ve worked on. Poor requirements usually lead to slower development times and features that are more likely to need rework. As an engineer, I have enough work to do in figuring out the best way to architect and implement a feature without having to frequently halt my work and chase down vague or incomplete requirements.
I did a lot of thinking and came up with a pretty comprehensive checklist of things I’d like to see in every feature request/user story/programming task. Read more on A Checklist for Great Feature Requirements…
In Douglas Adams’s Hitchhiker’s Guide to the Galaxy series, an advanced civilization builds a supercomputer to calculate “the ultimate answer to life, the universe, and everything.” After millions of years of calculation, the computer finally gives its answer: forty-two. Despite being an advanced civilization, it succumbed to the pitfall of getting an answer without first understanding the question.
We often fall into the same trap. I once worked on a development team that practiced Agile programming. Every now and then the team would debate whether we were really practicing Agile, whether we should do more Agile, whether we should abandon Agile altogether, and whether we should adopt some other methodology. The debates centered on personal preferences and impressions of team productivity. Alternatives were suggested based on what the team had tried before and who had what certifications. Never did our conversations start with understanding what problems the various disciplines were designed to solve. Neither did we begin with the most important question: what problems were we trying to solve? We jumped straight to the answers without first understanding the question. Forty-two. Read more on Considering a New Methodology? First, Understand the Question…
When managing a software project that has both design and development scope, I have come to prefer using an integrated backlog of tasks and separate burn charts to track design and development efforts.
Atomic continuously experiments with project management practices that help our poly-skilled teams manage their efforts and predictably deliver custom software products.
I’ve previously written about using integrated backlogs and burn charts and noted in my post that an integrated burn chart can be a bad solution if your team will have people inconsistently allocated throughout the course of the project. Inconsistent allocation can be problematic for burn charts regardless if the team member is a designer or a developer, but I’ve found through experience that it’s almost always true that the design effort on a project will have inconsistent allocation. The potential burn chart distortions resulting from inconsistent designer allocation are also likely increased due to a hours per point skew between design and development tasks. Read more on Pitfalls of Integrated Design and Development Burn Charts…
Estimating a new project is hard and time consuming. Why? Because when you start a new project, you are at the point of maximum ignorance. In most cases there is a solid idea, but the required functionality is ambiguous.
The business is depending on you — the engineering team — to identify a high-level timeline.
I estimate a lot of projects like this every year. Here are a things I do to cope with that ignorance and ambiguity.
1. Select the Right Magnitude
Begin by deciding a uniform level of precision for your estimates. If you think the project is going to take years, then your estimates should be in weeks. If you are guessing months, your estimates should be in days. And if you think the project is going to take weeks, you should estimate in hours. Read more on 5 Tips for Estimating at the Point of Maximum Ignorance…
Most of our projects here at Atomic Object take just 2-6 developers. But sometimes we work closely with other teams that are much larger.
On my current project, we’re part of our client’s much larger team, about 20 people. The team started out small, and as we’ve grown in size, we’ve had to refactor our project management practices as well as our code.
Here are a few of the ways we’ve refactored our Agile process.
1. Keep Your Stories Small
At a smaller size, we were successful with having stories that were about a week or less in size. As we have been growing, these bigger stories have been causing us some pains. Lowering the maximum size of a story to 2 days in size has worked well for us.
Read more on 7 Ways to Keep Your Big Project Agile…
Most developers have been beaten down by time-to-market pressures in developing new products, from time-to-time. And some more than others… depending on the culture, maturity, and size of the organizations they operate within.
As time wears on in these tough situations, morale takes a nose-dive and bitching ensues as a way to cope. Digging yourself — and especially the team as a whole — out or these ruts is a difficult undertaking. Deep ruts are almost never caused by a single factor, and as a result, can’t be overcome by a single magic solution, nor in a short period of time. It takes patience, time, and persistence to get the train back on the tracks to allow the team to thrive once again, or maybe even for the first time.
But it can be done. Read more on Getting the Train Back on the Tracks – Turning Complaints into Solutions…
If you’re reading this, you have probably ended up in a stranglehold of a mountain of seemingly-insurmountable “technical debt” at some point or another in your career. And you are probably also wondering if I have some magic recipe to extricate it from your future?!?
Or maybe you, like me, have, once again, run into the wall of resistance when you want to address a structural mess that’s makes everything you do more time-consuming than it should be. Maybe you inherited it? Maybe you wrote it? Maybe you have been building this house of cards for months — or even years — as you’re pressured into delivering features in less time than you really need to do them justice…
Whatever the backstory is, you’re in a slump, and “un-slumping yourself is not easily done.” (Thanks to Andy Brandt for identifying these categories.) Read more on Poor Structure and the Growing Burden of Tech Debt…
If you’ve worked on a large development team, chances are you’ve been in my situation: I’m near the end of my project’s release cycle, the code streams are locked down, and there’s very little new development to do. The bugs are getting more obscure, further from my code, and more difficult to reproduce. It’s tough to sit down in the morning and find something that I can knock out on my own. So how does one stay motivated and productive during times like these? Here are a few things I do to stay busy.
Volunteer to Work on Those Critical Defects
I know, I know. The last thing you want to do is get stuck on a high-visibility, high-stress bug that you can’t reproduce and isn’t even in a part of the application that you know very well. The trick is to make sure you are paired with someone who does know a thing or two about the area of functionality and pull in experts as you learn more about the problem. At a minimum, you’ll build some deeper relationships with people on your team as you go through the fire together. You’re likely to learn a great deal about areas of the application you aren’t familiar with and about tools you don’t normally use.
Read more on Staying Productive at the End of a Release Cycle…
Atomic Object has worked with a diverse set of clients throughout its 12 year history. And within each of these clients are individuals who we interact with on a weekly — if not daily — basis who have a different roles, skills, goals, motivations, and personalities.
Communicating regularly is important to maintaining a good client relationship. It’s also just as important to adapt what you communicate and the style in which you communicate it based on the individual you are interacting with.
Adapting your communication style and being concise will more effectively demonstrate the value you are providing to a client. For example, an automotive mechanic who demonstrates the value of performing a tune-up (increases the life of the car, better gas mileage, quieter, long-term savings, etc.) instead of describing all of the mechanical nuances of performing the tune-up has a better chance of convincing the client they need a tune-up.
There are three guidelines I’ve learned to follow when communicating with a client:
- Empathize with their position.
- Avoid jargon if at all possible.
- Be concise, and avoid superfluous details.
Read more on Adapt Your Client Language…