The world of programming like many others is evolving continuously and there are changes happening that have the potential to shape its future.
Finding it hard to predict 'agile' delivery dates? Here are the 2 metrics you NEED to get it done.
Agile professionals have often discussed what the exact role of a product owner should be in Scrum. What virtues should a product owner possess to be considered a “good” PO? The answers are many. And this is not surprising because Scrum is a framework, and its implementation in a project depends upon the requirements specific to the project. When requirements change, the role of the PO also changes. Therefore, it may not be possible to standardise the exact role a PO should play in a Scrum project.
It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.
I think that anyone who writes code in any shape or form should feel free about calling themselves a codesmith. The ideals of craftmanship should be followed, with a healthy dose of pragmatism, but learning the skills to become a good coder takes time and experience.
Service businesses are a great to get started with your entrepreneurial dreams. Bring your skills to the table, execute work, deliver it on time, and get paid – as simple as that. Service businesses are not the right vehicle just in case you wanted to do more, grow big, scale as big as you like.
Unless a candidate is considered superlative, non-local applicants are not always given the same level of attention as locals. Why might remoteness impact interview decisions (even in a tight market), and how can the potential for negative bias be minimized?
Maybe it is a navel gazing exercise for agile-folk but it does seem to be the reoccurring theme. And I can’t get over this feeling that some of my peers think I’m a bit stupid for continuing to support estimates.
OK, I confess, I use OSX almost exclusively and have for a number of years now. I love the hardware, but the OS and specifically it's lack of a software package management tool has just a level of suckyness that irritates me.
I hear developers talking of Right and Wrong. What would happen if we got better at describing Cost and Value?
If you want to walk fast, walk alone; if you want to walk far, walk together
I recently had a discussion with a CFO of a technology company. Ten minutes into our conversation he said, “so evangelism is pretty much rogue sales”. Internally I cringed. I politely corrected him that the two could not be further apart.
In my experience some risks for delivering these projects on time and on budget might be identified by a project manager early on in the initial inception phase of the project and might be reviewed at the end of each project, but not much attention is paid to the risks during the life of the project.
My professors taught me structured design and design by contract. Those were supposed to be the silver bullets for programming. I thought I was the only idiot that structure and specification didn’t work for. Why did I have to iterate and increment?
What makes a successful project? Waterfall project management tells us it’s about meeting scope, time and cost goals. Do these success metrics also hold true to agile projects?
Now if you are a SOHO developer then you might think that agile practices are irrelevant to you. I would disagree.
A number of the teams I work with have been looking at the Primitive Obsession code smell recently. As we have explored legacy code looking for examples of the smell, I’ve noticed a tendency to enthusiastically label every primitive in any method signature as smelly. I so wish Fowler and Beck hadn’t used this particular name, because it seems to spread as much confusion as enlightenment.
We are in a world with lot of learning opportunities. But how much stuff do we really learn? What holds us back from learning new things faster?
When speaking to architecture, SAFe refers to architectural runway, not architectural train tracks or a rail-yard. It’s a mixed use of transportation metaphors that is not explained. The runway is a perfect alignment with my Release Plane metaphor.
Don't fall into the trap of falling in love with your own code.
I’m normally not a fan of reducing human behavior to a list like this, but it seems pretty complete, and the words resonated.
Until more developers get more training and understand more about how to write secure software, we will all need to lean on static analysis (and dynamic analysis) security testing tools to catch vulnerabilities. But static analysis isn't a substitute for code reviews.
Most of us have been there... the release or sprint planning meeting to goes on and on and on and on. It doesn't have to be like that!
This post is about how we may accidentally harm organizations with Agile and how we can let go so that we may succeed.
I believe that there will be a time when IT, like teaching and accounting, will have more women than men.