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.
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.
How does it happen that an individual gets an idea to come up with a product or an app? It quite often originates in this individual’s personal need to have an app that would help him or her do the things they need to do, or enjoy doing.
Even though there are hundreds of articles professing the beauty and efficiency of the one page résumé, not a day passes where I don’t see a five pager.
When I was younger I thought becoming a manager would be great because I would have all these “resources” to guide, direct, even bend to my will. Luckily I was never made a manager.
I hear many references to organizations wanting to follow the advice of Steve Jobs and to have only what he called "A Players". What's lost in that "sound bite" is that Jobs' went on to flesh out that notion that A players can come from many backgrounds, bringing talents from many different disciplines.
his is an outline of the problems that we have as an industry building secure software: why we fail at it, why Agile development is blamed for insecure software, and what we can do to build more secure software while still being Agile.
I have always found it hard to differentiate an Iteration from a Sprint, so much so that I commonly say they mean the same thing. They are synonymous. I use the two interchangeably. The difference is historical, the term “Iteration” originated in XP and “Sprint” in Scrum.
When I talk to people about working remotely the focus is often on the tools. I’ve noticed the real challenge is the working relationships and maintaining these even though we are hundreds of miles apart. Working effectively as a team means considering everyone's needs
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.