The corollary to Vertical Divide and Conquer is Conway’s Law, which tells us for our vertically aligned business and technical capabilities to be truly successful we must also re-structure our organisation so that our development teams are vertically aligned with singular responsibility for specific business capabilities.
Nearly every reason put forward to offshore your development team gains more value from first reviewing and addressing other areas within your business that need real attention before considering offshoring.
A new etiquette has emerged for remote working. Without it uncertainty can leave words unspoken and replaced by assumptions that lead to conflict.
The subject of keeping fit creatively is tied to productivity in most “booster” books, but productivity and continuous problem-solving are two different things. I’ve come to this conclusion over many years of what I call “living and exploring”.
Since I’m bringing my TDD spaceship to Agile Testing Days (October 28th through 31st in Potsdam) and Agile Eastern Europe (October 4th and 5th in Kiev), I’ve created a short video depicting in detail what led me to do this.
It’s been two months already, and Agile Eastern Europe is long past. Which is why it is a good opportunity to put my talk there “Not the agile I used to know” front and center.
Here is my current thinking on how I communicate and consult around Agile. For me, it’s all about understanding the desires and wishes of the organization I am working with and mapping that to an approach to Agile that fits their context.
Today’s internet is rife with fascinating subcultures, many I’d never heard of. Parmy’s book on Anonymous takes us to the door of all these places, and gives us a candid peak at what goes on there. Kids these days are up to no good!
Although many successes are seemingly interlaced with failure, some find ways to endure and grow. Why is that? One common area of growth is a developer's analytical abilities. Skepticism can be a valuable tool in a developer's tool belt, but like most tools it is only needed at certain times.
I have a long love/hate relationship with running and I think that it's a great metaphor to help explain the subtle differences between agile practices and traditional development. In software development, agile practices are the equivalent of the type of running done in soccer...
Are your Agile projects failing no matter what you do? Have you tried getting new devs, firing old managers, etc.? You may be experiencing the phenomenon of Institutional Memory, where the ghosts of past failures live on in the collective conscious of your organization.
Carrying on from my previous posts applying the economists' tools to thinking about software development (Supply & Demand in software development and Software supply over time). In this post I want to see what happens when we apply Agile...
This week we're talking to Vlad Mihalcea, software architect passionate about software integration, high scalability and concurrency challenges.
Because your office is designed for people who employ people they don’t trust. For people who work because “the man” who pays them is watching them. It keeps them busy, doing the wrong thing, and there was no choice
A colleague’s statement, “In fact my tip is NEVER do a MoSCoW prioritisation,” caught my eye. “The implied fixing of scope makes change very difficult. Order things instead.” That bold NEVER waves a red flag. The following exhortation to order the things to do is also troubling to me.
The first step in any agile transformation is transparency. A Kanban board, which exposes work and its actioning in response to certain signals, is a good tool for encouraging this practice. In this post we look at how transparency is attained and at the controversy that is often involved.
To reach the ultimate level of success and truly increase your value, you have to have both style—the ability market yourself and make a name for yourself, and substance –the skills that pay the bills.
Our practices revolve around keeping the team engaged. My goal is to give everyone enough space to think and opportunities to collaborate. The practices are similar to what you might see on an Agile team, the difference with remote work is they need to be more deliberate.
Though the status quo is killing their organization, some barriers to further Agile adoption happen way too often among organizations that need it most. I was asked to actually list some common barriers others have dealt with.
Managers don’t want to think harder than they have to. They like simple rules of thumb. One of the most useful rules of thumb is the 80:20 rule. You can see obvious cases where the 80:20 rule applies in software without looking too hard. For example, 80% of performance improvements are found by optimizing 20% of the code.
Developers are driven when they can architect their own solutions to problems. Nobody wants to implement someone else’s idea, especially one they may disagree with. Give your engineers (even the junior guys) the ability to get a say into how something is designed.
You can categorize developers into three motivation types: Business-Motivated, Technology-Motivated, and Problem-Motivated. And a 4th category of those who just don't give a crap.
What process or methodology did we follow? “Do what makes sense!” Yes, that was the only thing that was told to me the first day I joined the team. No process, no compliance; only sensible things.
ATD 2013 was my first testing conference. I didn’t know what to expect. Sure it has “Agile” in the title, so it can’t be all about testing, right? Yet the agenda seemed a bit unfamiliar.