Not your customer, not your manager, not you, but your team, needs to ship. They need to see their work get out there. They need to see people using it in their hands. They need to hear the pain of users. They need to understand what people are seeing and how they are using. More than anything, they need that achievement, no matter if they crossed the finish the line at a gingerly pace or…
Your releases, your successful releases will always, always be wrapped into those two behaviours. Look back on the releases that went well and think back to all the activities you undertook and you will see they are rooted in these two behaviours. You might not have to think about them when starting a release (great), and if you do, that’s okay too. But know without either/or you have a long hill to climb.
I wrote about Architects in Code Your Way Up but felt the need to digress on the topic a little bit here in a recent post on Dev.to I’ve always found the title of Architect to be a little self-fulfilling, i.e., I want to be a “title” so give me a title that sounds cool and in software, I fear that the term of “Architect” has become one of those titles. The implementation varies across…
On a big initiative, where you have a lot of people reporting to you, where you have a big team and lots of money behind you it’s easy to be swayed into worrying what people are thinking and how they are viewing your progress. But just like with a small project, all that matters is the client. Nothing else.
I’m not big on methodologies, because there are so many ways to solve so many problems that boxing yourself into one mindset sounds very scary. If you’re open to change, great, but often what I see is people not being open to change when they “adopt” a methodology. There are many hurts that can come from Agile, but the big one, is the adoption. If only one group of your company is using Agile, they…