For no reason other than LinkedIn communications are starting to irritate me, here's my personal LinkedIn Etiquette guide. Feel free to disagree with it all.
It’s been more than two years since I wrote “4 signs that agile is declining”. I gave a talk at Agile Eastern Europe (which hopefully will be up soon) that revisited this topic. Here’s a summary.
Many organizations have a system test team or integration team that is separate from the Scrum delivery team (the Design-Build-Test team). I sometimes get questions like those above from such organizations as they consider adopting an agile approach, particularly from large organizations that have to integrate the work of multiple teams.
It feels great. Yep, since we went remote, pairing has become really popular. No sharing body odour with your colleague, we just share our screens with a headset on. We may be separated by hundreds of miles but everyone is usually equally accessible.
SaaS onboarding seems like an odd concept to the uninitiated. Implementing a secondary system to integrate into an existing web interface would once have seemed like something that would be not only redundant, but barring that, impractical and too taxing.
This is the 3rd post in a three part series about quitting your job and working for yourself. Check out the first post about why you should want to quit your job, and the second post about the fantasies and realities of quitting your job.
Do I believe in program management—one person to coordinate the efforts of everyone—for large programs? You bet. Do I believe in project management? You bet. Am I one of those people who believe in agile project management for geographically distributed teams? Yes, sirree. How about projects and programs where people are clinging to their silos? Absolutely.
“Wet agile”, “the agile waterfall” and “the Agile-Waterfall Hybrid” … this controversial, mixed-method baby has as many names as formats. Some have received a lot of dedicated thought, are fit-for-purpose and manage to preserve the main benefits of the more pure methods.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (week of Oct. 26 to Nov. 1).
Gathering requirements is an important part of any software professional's job. Learn about a few tools you can use to help this part of your career.
The truth is, the number of struggling projects far outweigh their successful counterparts. Why is this? Because sometimes developers are too smart for their own good.
The #NoProjects meme is catching hold, mostly as a rejection of forming project teams. Meanwhile I’m intrigued by the ideas put forth by Carmen DeArdo of Nationwide Insurance during a webcast on DevOps on Tuesday. Ok, #NoProjects people, tell me what you think of this approach.
In this article we consider a hybrid agile approach known as Scrumban, which can potentially address both project and BAU work. Scrumban is becoming increasingly popular and has significant ramifications for project scalability.
Ever been a part of or observed just a really terrible Daily Scrum? Tobias Fors has, and he tells the story of it in his blog post "The Worst Daily Scrum Ever."
Because Agile development teams work from a backlog of stories, one way to inject application security into software development is by writing up application security risks and activities as stories, making them explicit and adding them to the backlog so that application security work can be managed, estimated, prioritized and done like everything else that the team has to do.
I had a meeting with a stakeholder who stated “I bet you wish I wasn’t in these meetings”. My reply was that it would be much worse if she came in at the end of the project and told us we had just built the wrong solution.
I have stepped into my 12th year of practicing Agile methods. Even now, organizations are looking at Agile as a silver bullet without fixing the root causes. The issue is that Agile was born mostly to banish the problems coming out of the Waterfall model.
The larger the effort, the more we need to estimate. And, the more your estimate will be wrong. The more we estimate, the more we have schedule games. That’s why I suggested you use agile approaches. You can break things down, and iterate.
Working for yourself is much harder than you might imagine. When you are working for yourself, you are only getting paid if you are working. You don’t just show up and get paid.
I picked up Daniel Kahneman’s "Thinking Fast and Slow" after a recommendation by Mike Jones in early 2013 – it’s taken me quite a while to get through it. The book starts by describing our two styles of thinking…
It was 2001 when a project manager first put my job title as architect on a statement of work. A lot has changed over the last twelve years. One of the problems I see these days is that we are expecting every developer to have architect skills.
Most hiring issues can be broken down into one of three categories: constraining factors, improper vetting, or lack of awareness. The following sections outline the problems found within each.
This year’s Agile By Example (or simply ABE) was my 2nd visit to this conference, I’ve missed only the first edition. Last year I felt really refreshed by the conference built not only around code, coding, testing and developing software.
On Thursday, I did a “Speed Mentoring” event at Google, where a Barnard & Columbia woman had five minutes to ask a Googler questions and then we’d move on to the next student. It was an odd format for mentoring, but I think by the end I had a useful set of quick advice for undergrads. Here it is:
As a seasoned IT professional what would you choose: working in an organization filled with managers, with no vision and mission, or for one of the above, given that your salary and benefits are more than fine?