There was some hubbub a few months ago when it was revealed the Executive Director of the UK’s Year of Code initiative can’t code. Apparently a number of people don’t agree with the idea that competency in a domain is a requirement to manage that domain. I find this idea infuriating and it can only end poorly.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (Apr. 04 to Apr. 10). This week's topics include discussions of the prototype of future knowledge workers and software developers, a video about how meetings feel for engineers, and why you shouldn't estimate spikes.
It is important for technology companies to think of ways to boost their employee’s morale and help inspire them so that they can become more productive in their work. To help leaders and even managers out there, here are some amazing ways that they can use to boost their employees' morale.
Everybody makes mistakes, otherwise we would all write bug free code. For most of us a mistake can be fixed and doesn’t have too serious consequences.
When Lean goes awry, Toyota- the company and its principles, practices, and culture- is there to set things straight. Agile has no such entity. Instead, we have hundreds of “Agile” shops who attribute success to some (non-)Agile practices. The corruption and perversion here is inevitable.
While every intranet is different, there are some common factors that need to be considered so your intranet supports your business requirements.
There is a simple heuristic, which you can use to determine the top priority activity you can engage in-at any given moment.
I believe any technical leader has a responsibility to review all the code that goes into a codebase.
To do a great job, product owners need a strong ScrumMaster at their side. This post explains the differences between the two roles, what product owners should expect from their ScrumMaster, and what the ScrumMasters are likely to expect from them.
We work with our brains rather than our brawn. We generate value because of what we know and what that knowledge allows us to do.
The other day I was watching Kent Beck’s talk about Ease at Work. It touched me deeply and I could really relate to what he described.
If you implement all of your spikes for each release in a “Sprint 0″, you could estimate them. If you do, do so always so that your velocity will be reliable. Spikes are, like defects, generally harder to estimate correctly relative to user stories. It’s best to time-box them.
The guy who had written the code started formulating the text while my friend was typing. The other guys commented if they didn’t agree with the content or the wording. A few extra PCs where brought in so that the guys who weren’t typing could look up facts, run simple tests or chat with other people that had input.
There's a great annual conference coming to RTP for the first time on May 2nd. The stellar speaker lineup includes four concurrent tracks with six sessions, not counting the morning keynote.
The underlying issue is tribalism vs. inclusiveness. Do we work hard at empathizing with others and trying to include them or do we settle into a new tribe that aligns with some short term goals? Sadly, most of what I'm seeing in tech these days is simply a realignment of tribalism.
Highlighting IT workers as knowledge workers allows us to learn from the existing body of knowledge on the subject.
And here I share my newest fun story (a video this time): An engineer as an ‘expert’ in a business/requirement meeting. The task is simple: create seven red lines. But the twist is that these lines must be perpendicular…
Consumer Release Testing exacerbates the original flaws of Release Testing. A high value, low cost alternative to Consumer Release Testing is for the consumer and provider to actively cooperate in risk reduction, which can result in a substantial reduction in provider risk.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (Mar. 28 to Apr. 03). This week's topics include the virtues of Agile's lack of "control," what Carl Sagan can teach us about lab-lecture balance, and the dangers of allowing Agile to be controlled by non-developers.
When someone else tells you what a standard for your work has to be? How does that feel to you?
Let those people creating the software, create the system of creation too.
The thing about writing software and especially about writing for open source projects is that the secondary audience becomes an even greater factor. Even if the code speaks for itself you should still create documentation. Something is better than nothing, good documentation is better still.
Abstraction is one of the key elements of good software design.
It helps encapsulate behavior. It helps decouple software elements.
What if we were able to set expectations beyond a simple number? What if we could say what we know and what we don’t know? What if we could give our best estimate now, and give a better one next week when we know more? Would that help?
There are essentially two types of Open Source: Hobbyist’s Open Source and Professional Open Source