This week we're talking to Claus Viscuso, open source advocate, OO software developer, and developer evangelist at Kii focusing on MBaaS and Android.
In a distributed Agile project, team members may not often see each other face to face, but must work collaboratively toward a single outcome. The reasons for distributing your Agile team will be different for each organisation.
Lean thinking describes seven classical sources of waste. Here are the seven wastes of enterprise information application architecture:
I have developed a new goal-oriented agile roadmap — the GO product roadmap, or “GO” for short. GO is based on my experience of teaching and coaching product managers and product owners, as well as using product roadmaps in my own business.
When you ask for permission to take a vacation, you are implicitly saying that work is the higher-order item in your life. I cannot tell you how many people fall into the trap of thinking that they should schedule their vacations around their work schedule.
I have blogged before on the subject of “What is Agile” - I’ve even expanded on that blog in an unfinished piece of writing called “What is Agile? Perspectives on Agile” - but sometimes I think it's just sex....
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.
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.
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.