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…
How are you designing solutions with your team these days? Are you designing solutions with your team? Or are you handing it off to them to and hoping they figure it out on their own? If you don’t have the latest or greatest you might need to start getting a little creative in what you do; Building a template in PowerPoint or even paint to get your point across.Augmenting your requirements with workflows to more…