If you are repulsed by the concept that your elbow-rubbing skill may be integral to career success, or are perhaps uncomfortable in traditional networking situations, please continue reading – it’s less necessary today than most think.
Today I want to share some more details on when it is potentially not enough to have one product owner. You might want to watch for those signs in your teams, and then act as needed.
We have to take the rough with the smooth when it comes to agile adoption. Some clients make cheering progress while others advance at a glacial pace. In short, we must be prepared to facilitate agile transformation in organizations that suck.
Failure happens. On the Internet when we talk about failure, we generally mean pictures of vehicles in strange places, large scale (and confusing) accidents and animated gifs of cats being cats. However, in Agile Business Management (and Agile in general) failure means something different.
A few times recently I've been asked about retrospectives -- specifically how to keep them from becoming a gripe session. Here are a few things that I've found effective:
What if there were way that you could use a spare hour here and there and use your development expertise to help out charity organizations? MakeADiff is a place where vetted charitable organizations can post their tech projects they need help with.
In this presentation I attempted to drive toward a shared understanding among the group as to how we could better understand the challenges of distributed teams and how to accept them — not working for or against them.
There is a myth that just by embracing Agile or Lean, one could build innovative products. Based on my personal experience working in several research projects and being part of innovation team, I have found that we need much more than Agile.
When I tell people that most of my team pairs most of the time, and that it’s not mandated, they nod and say “Yes but I don’t think my developers would be happy doing that.” Why are people reluctant to pair?
Matt Wynne just blogged about conferences that have a high proportion of curated content. I didn’t attend the conference that sparked Matt's thoughts, but I do tend to agree with his sentiments. Here are a few random responses of my own:
I know a lot of Agile folk will see Evolutionary as superior, they may even consider Evolutionary to be the only True Agile but actually I don’t think that is always the case. There are times when the other styles are “right.” Let me describe the three styles:
Scaling Agile across the Enterprise attracts a lot of attention these days. In an organization, everything has influence throughout the organization. Given this, how do you institute change in an organization?
My conclusion from these experiences is that we act when we feel pressure on our wallet. With weekly billing the client will pressure their own teams on mutual accountabilities. They’ll also pressure you the consultant or service provider. So be prepared to pull your own weight.
In my view, unless you are doing real IT architectural work and have years of experience in IT and the architectural space you shouldn’t use the title of "Architect." We, the IT industry, need to do better with titles or we will continue to devalue ourselves in the eyes of our customers and this is a way to get to solving that.
Trust and respect are two very important words in software development. They can influence hiring, firing, personal interactions, and building teams. The importance of these words is only overshadowed by their complexity.
In the past, the team was used to the analysts completing all of the requirements in advance. The delivery team would then execute on those requirements. The problem, of course, was no shared understanding.
Advice on salary negotiation is abundant, but material written for the general public may not always be applicable to a technology sector where demand is high and the most sought after talent is scarce.
The software industry is obsessed with hiring. Every week we get new articles on the topic on how to snag those mythical 10x developers. The elephant in the room is that most developers can do most corporate jobs, so perhaps hiring is just not as important as we give it credit for?
On September 24th, 2012 my sole proprietorship was officially registered and I became a business. Since then my rate has grown by 100%, my availability has dropped to essentially zero, and last week I hired my first intern. Life is good.
Speaking of unfair interview questions, this would be a pretty evil one. Can you see the bug? How would you fix it?
When trying to be defensive, programmers often end up being paranoid – that is, desperately pounding at the problems where they see them, instead of dealing with the root cause. An offensive strategy of letting your code crash and fixing it at the source will make your code cleaner and less error prone.
Connected teams, teams who know each other will always deliver more and better than teams who don’t. That’s the future of work. How you make connected teams? That’s up to you.
I'm a great believer in getting kids to code early. We want to open kids' minds to how their world is constructed, and show them that they can influence it. They can control it. They can change the world.
I love this workshop. I ran it at Scrum Gathering Paris and it seemed to work beautifully again. There were some great ideas about how we can start to overcome the "us and them" mentality.
Even as our tools have improved and as we've strengthened our testing capability we keep doing reviews because bug checking tools, reviews and testing find different problems and different kinds of problems.