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…
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.
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.
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?
In an open, self-regulated market, the tools gravitate toward their corresponding, welcoming environments. Low-trust tools go to low-trust, highly regulated environments, and high-trust tools are used in agile, high-trust cultures.
My recent “#NoProjects - why projects don’t make sense” post stirred up a fair bit of discussion, both on the blog and especially on Twitter. But, while that post railed against “projects” it didn’t say much about what we should do instead. So let me try and put in place the outline of how I see a #NoProjects world working.
I personally think that being “agile” is truly what makes a company “Agile.” Just like how happiness is a journey and there is no “permanent” state called happiness, being “agile” is a journey and there is no final/permanent state called “Agile”.
Agile principles are all about learning as you go and using the new knowledge to redefine the goals of the project. This is perfect for the developers and the immediately involved business representatives. But for a C-level exec it becomes hard.
Are you working in the way you are because it’s a good idea, or just because someone told you to do it? I die a little bit inside when people say “should we do Agile or not?” The assumptions behind this question are all wrong: That there is one way to “be Agile”
Many software developers I’ve talked to have expressed interest in the idea of someday either starting their own business, or in some capacity working for themselves. Before you do really quit your job, you should first understand why it is a good idea to quit your job.
This post is an excerpt from my new book, Conversational Git. The entire book is available online and its source is on GitHub. It’s designed to be a quick, accessible introduction for experienced developers. I’d be delighted to hear what others think.
Maintaining focus has become a such sticking point for so many. How do we keep it? How is it so easily lost? What tools can we use to find it, induce it, or retain it? If you’re constantly seeking focus and it seems nowhere to be found, you may need to ask yourself: how driven are you, truly, in what you do?
Scrum took over when more players started promoting “Agile” as it had stronger and clearer management. The ‘My Supply’ project at a TW client was in back 2002/3, and fully XP.
The average developer makes hundreds of decisions every day. This applies to programmers of all types including newbies, seniors, leads, and architects. How we make these decisions can make all the difference.
A couple months ago I started a series of posts about communication (see Non-Violent Communication for Agile Teams). The concept of non-violent communication has been introduced and championed by Marshall Rosenberg in his notable book.
Abi Crafter at Countersoft liked my “11 Myths and 2 Truths of Agile” blog entry so much he turned it into this Infographic. Thanks Abi!
Guy Lawrence – former CEO at Vodafone – tells of an organizational transformation effort that is intrinsically tied to office renovation – he says: “Conventional offices and working is dead”. The motivation for undertaking these sweeping changes is to have people from Generation Y (born after 1982) actually want to work at Vodafone.
A kegerator is a staple of the modern startup, and smart tech businesses know that it's a great way to attract talent. Developers love beer. But does it make a workplace unsafe, less productive, or encourage harassment?
Disruptive technologies, and disruptive practices, can cause good managers to fail. This Chapter explains why a new management model is imperative and characterizes the market ecosystem in which software development teams must operate.
A while back when I was working in a global banking organization we requested two virtual machines for development and testing. Why did it take so long to deliver virtual machines, and why could they not deliver consistent, working machines?
Scrum Teams who follow a system's journey into service often find that work becomes more Kanban-like. In this article we examine the challenges and gotchas of moving from a project context to "Business As Usual".
If you make your project portfolio decisions based on money, estimated cost, you too will have Sony’s problems. This is why cost is the wrong question to ask. You want to ask the value question, “How much value will this project provide?”