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
The point of using agile is to get finish something valuable-to-the-business quickly, to get feedback. Agile is all about change.
Protoypes are good. Well I think so. They give you a better idea of how an application should hang together, where the abstractions are, where there are opportunities for refactoring and re-use. But are there downsides? The classic one is that a prototype sometimes becomes the production code.
What I’m saying is that for candidates with similar extrinsic abilities, their intrinsic abilities will make a much bigger difference in their performance. Don’t overlook a possible standout performer because their extrinsic abilities aren’t a great match.
Release planning is without a doubt one of the most challenging responsibilities for agile teams.
One common complaint about agile methods is that management doesn’t have the same degree of “control” over projects. We need to stop worrying about this complaint as a vice and start thinking of it as a virtue.
Neil deGrasse Tyson talked some about how stellar of a scientist Carl Sagan was and what an impact Carl had on Neil personally. What a reminder for those of us that have moved into managing and left behind creating. Should our dues, once paid, last forever?
Do you use coding conventions? They help the code to speak for itself and make the learning curve a little less steep. However, do some conventions get in the way more than help?
Agile was a developer thing, and now it’s out there in the hands of the uninitiated.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (Mar. 21 to Mar. 27). This week's topics include two discussions of Reuse, the ethics of producing open source code, a contrary view of mandated agile, and the top 10 persons that could hinder a daily standing meeting.
If you use personal kanban for a while, you can start to track how many cards you can do in a day and use that for your planning.
Many time, in the middle of developing a user story, the programmer discovers a question about how it’s intended to work. Or the tester, when looking at the functionality that’s been developed, questions if it’s really supposed to work that way.
Next time you hold a daily standup, see if anyone exhibits any of these 10 behaviors.
Once the organization's inertia is known, this can serve as a prediction how long it will take to increase the organization's delivery rate with a certain amount and is related to the business case of Agile Transformations.
If we’re doing things correctly, almost everything we write should make the next release or next project easier. Effective reuse taps into the passion developers feel for great code, leading to greater creativity and productivity. Besides, how many Foobulators does one company need, anyway?
As someone who has been around programmers (and ran a Java Users Group) for about 15 years, I often guide senior technologists in marketing their skills. I generally advise my clients on employing some senior level engineers who are strong coders but will also serve a secondary purpose of attracting other less experienced hires.
However, my software developer "build a better mousetrap" instincts took over and I decided to write the report generator myself. But no one used it.
We use the phrase "eating crow" to describe a situation when you must admit that you were wrong after taking a rather strong position about something. While this isn't exactly that case, hence the second title, it does illustrate a lesson in perspective.
Organizations generally go with copying the practices/strategies from other popular brands/companies with the assumption that it works for them. In reality, it won’t.
If you need the same functionality in two projects, you should reuse code between them, right? Or should you? For as long as there has been a profession of software engineering, we have tried to achieve more reuse. But reuse has both a benefit and a cost. Too often, the cost is forgotten. In this article, I examine the economics of reuse.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (Mar. 14 to Mar. 20). This week's topics include the programmer productivity paradox, the 10 commandments of programming, and 5 tips on how to sell your ideas effectively.
Sometimes proponents of Free Software make it sound as if you must give away all of your code as Free or Open Source Software (FOSS) if you want to be an honest and moral software developer. This is not the case. Morally motivated developers don't always have to give away their software. In fact, sometimes they should not give away their software. Here I explain why by drawing on some basic notions of moral philosophy.
Not all mandates are bad, and some are necessary. Creating such a false dichotomy serves no one in the long term.
Don’t confuse a Shu level implementation of enterprise agile with a by-the-book implementation of Scrum. Your organization may require more advanced mechanisms to implement agile at scale. What you need is one combination of approaches that works consistently while you are getting started.